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[57] 



ABSTRACT 



In a network communication system passing messages 
between gateways via a message handling system the 
gateways are interfaced specifically to their respective 
network access units and are interfaced generically to 
the message handling system using routines common to 
all gateways. Messages are sent in protocol data units 
including recipient addresses which do not identify 
recipient gateways as such; the gateways are used trans- 
parently.- The data format is CCITT 1988 X400 stan- 
dard with automatic conversion to and from this format 
at sending and receiving gateways plus automatic docu- 
ment conversion. Message handling involves waiting 
for many services and events. The invention allows 
calling routines to avoid pending while waiting for 
events and services. Service routines, including event 
watching and timer routines, schedule notifications on 
to queues and the main processing task runs notifica- 
tions off the queues by calling a run routine. 
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More specifically the improved system is intended to 
NETWORK COMMUNICATION SYSTEM be utilizable by PTTs (postal, telegraph and telephone 

authorities) to provide gateways which may be ac- 
B ACKGROUND OF THE INVENTION cessed by the respective access units for transparent 

1 tr u ~c *u« t *: 5 communication with access units connected to the same 

L. Field of the Invention system or another system installed by a different PTT. 
This invention relates to a network communication ZL^iT^^r LZmI k„ 
system for use in handling communications between The unproved system is equally suitable for use by 
y * . . J*""*" 1 * r~l ZZ other large users such as public and private corpora- 
access units which may comprise office automation - m - ° , v v v 

. ^ - r . -, ^ tions tor example, 

systems, telex, teletex, facsimile, etc. AnomeTo^ect of the invention is to avoid the need 

Abbrevutions and acronyms used heremaretoeda for routines t ^ nd awaitmg external results, even in a 
the end of the description. References to Data General threaded operating system. Such a routine will be 

are to Data General Corporation, the assignees of the ^ ^ rou ^ 

present application. The network communication system according to the 

Z Descnpfac-n of the Prior Art 15 favcntioil comprises a plurality of gateways or nodes for 

There exist today many proprietary co^unications respective access units. For example, one node 

systems and various mternational standards rekting to serve a facsimile network, another node a telex 

message handling and data transmj^on. Nevertheless Mtworfc ^ ateways a of p ropr ietary of- 

there is no system in existence which will allow all lands fice automation 9ystems such ^ C EO (Data General 
of access units to communicate freely with one another. 2Q Corporation), DISOSS and PROFS (both IBM), etc. 

It is true that there do exist gateway systems, known ^ or nodes ^ connected to communis 

commercially as Soft-Switch and Mailbus which are ^ ^ each other ^ a standard meS sage handling 
intended to allow interchange of messages between preferably the CCITT X400 Standard, hereby 

dissirnilar systems. However these known systems are incorporated by reference. X400 exists in a 1984 version 
essentially suitable for use by private corporate and 25 (denoted 1984 X400 herein) which has been imple- 
other large users because they utilize a proprietary mes- me nted by many users. X400 also exists in a 1988 ver- 
sage transfer protocol handled via a central processing sioQ (denoted 1988 X400 herein) and it is this system 
system which converts from and to the message proto- which ^ preferably employed as the "backbone" of the 
cols employed by the various gateways. Moreover they mve ntive network communication system. It is particu- 
are set up as complete systems in which each gateway 30 advantageous that the invention can thus employ 
has to know what other gateways there are on the sys- m accepted, international standard and not introduce 
tern and what are the characteristics of the various yet another proprietary message handling system. How- 
gateways, ever, since 1988 X400 is not yet widely implemented, it 
The known systems are neither intended for nor suit- ^ particularly advantageous to provide as one of the 
able for public services. 35 gateways an X400 gateway, which can interface the 
Another problem with which the invention is con- "backbone" to the somewhat lower-specified 1984 
cerned arises in conjunction with computer operating X400. 

systems (e.g. MS-DOS and UNIX) which are single Each gateway or node of me system according to the 
threaded, i.e. they can handle only a single processing invention comprises a network interface providing ac- 
thread at a time. This leads to the result that routines 40 c^ to the access unit or units served by that gateway, 
frequently have to wait if the processing path comes to This is the external, user-specific interface of the gate- 
a halt while waiting for an external event The routine is way. Each gateway moreover comprises an external 
said to pend Although other operating systems can message transfer interface (MTI) for sending messages 
handle multiple threads (e.g. AOS/VS) the system ac- to and receiving messages from the standard message 
cording to the invention is desirably not restricted to a 45 handling system, or backbone. 

particular operating system and should be capable of Internally each gateway comprises a software inter- 
operating with single threaded operating systems. Some face which is identical in all gateways and moreover 
systems, e.g. UNIX can simulate multitasking by hold- matches the message transfer interface. A library of 
ing a plurality of copies of a program in memory and core routines provide communication between the mes- 
scheduling the allocation of the CPU to the different 50 sage transfer interface and the software interface. This 
processes. However this is wasteful of memory re- library contains the bulk of the gateway software and, 
sources. MS-DOS has no built-in facilities for achieving since it is the same for all gateways, the invention avoids 
even this level of multi-tasking. the heavy expense of developing a lot of software spe- 

In a network communication system waiting for chic to each gateway, 
events occurs all the time, e.g. as transfers are effected 55 Each gateway further comprises a library of specific 
across interfaces, and single threaded systems lead to routines individual to that gateway and which provide 
inefficient usage of computer resources, for the reasons communication between the network interface and the 
explained above. software interface. These routines convert between the 

_ __ , ^„ ^„ vwvif^r/wT format and protocols of the network interface (which 

SUMMARY OF THE INVENTION ^ m $pecific ^ ^wy) on te one ^ ^ ^ 

The object of the present invention is to provide an . standardised format and protocols of the software inter- 
improved system which will allow access units to utilize face on the other hand. These node-specific routines 
gateways or nodes in an unrestrained way, without any represent a much smaller part of the software of each 
knowledge of the nature of the system or of the other gateway. 

gateways or nodes in the system. 65 Examples of the functions performed by the core 

The terms "node" and "gateway" are used inter- routines are as follows: 
changeably herein even although some nodes may not Assemble and transmit a packet of data to the back- 
by strictest definition be gateways. bone 
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Receive and disassemble a packet from the backbone format, without regard to the document formats accept- 
Look up destination address in a directory able to recipients, secure in the knowledge that if con- 

Submit a document to a document format converter version is necessary, it will be taken care of automati- 
All housekeeping function, such as logging and audit cally. 

trail, accounting, error handling. 5 Within the message handling system, such as 1988 

Examples of .the functions performed by the specific X400, there will be a standard address structure corn- 
routines are as follows; prising many parts for identifying message originators 
Convert from/to the format specific to the network ^ recipients. Most network interfaces will employ 
served by the gateway. different address formats of much more restricted 
Convert between addresses within the network 10 j^g^is accordingly preferred to provide at least one 
served by the gateway and within the host back- ^^0^ accessible to each gateway via the message 
°°ne. _ handling system. The library routines include routines 
The communications between the gateways anodes ^ identifyin ^ message originator 
on the standard mes^ge han^mg l5 and message recipient at an originating gateway to the 
protocol data units (PDlfs). ^ ™U c^r^ee 15 * Rectories. This is used to determine iden- 
X-400-an envelope part and a *j^P^ ™' drying o^ta in a standard form Cm accordance with the 

o^r^ 

SnTcata specific to tfae gateway serving themes- part of the PDU. Further routines submit t the identity, 
sage recipient In accordance with X400 1988, the enve- 20 ing data in the envelope part of a received PDU to the 
lope part, denoted PI, comprises primarily the origins directory or directories in order to determine at least 
tor, the destination, message priority and an indication the message recipient in the form which is required by 
of whether a delivery report is required. The message the network interface of the receiving gateway, 
part, denoted P2, comprises a header, which repeats Preferably the system comprises a mam directory unit 
much of the PI data and includes a subject title, a docu- 25 holding a directory which is directly accessible by all 
ment type identifier and the main body of the message. the gateways on the message handling sy stem. This 
This is a highly significant feature of the invention directory may be in compliance with the CCITT X500 
because it enables any access unit to send a message to Standard. However one or more subsidiary directories 
any other access unit without concerning itself in any he held in directory units within individual gate- 

way with the nature of the receiving gateway. Indeed 30 Such a c y rectory indirectly accessible to other 

the originator does not have to know that any gateways gateways via the message handling system and the hold- 
are involved. The system according to the invention is . gateway 

completely transparent to its users and can be installed ^ mventkm further comprises, as part of the core 
by PTTs to enhance greatly their message handling ^ ^ wnich ^ operatc ^ different 

capabilities in a way which requires ^ action on the 35 (such as AOS/VS on an MV com- 

part of end users^ What is more the system does not JJ^^g^ a PC and UNIX on an MV com- 
have to be reconfigured when a gateway is added or f uw = a » A , . „ n ?„ mA +rt „ 

removed Of course, users have to know the addresses P*er or other hardware). The interface is referred to as 
vXvl^ communicate but the fact that a General Unpended Interface, GUI Under GUI, when 

they are on various gateways does not have to be 40 a routine wishes to make a request of a service provider, 
known. This is because the envelope part of each PDU specifically a GUI-conformant service provider 
does not contain any data specific to the gateway serv- (GCSP) the user calls the relevant routine but does not 
ing the message recipient. All messages simply go out wish to wait for its completion. Rather, the user is ln- 
onto the universal messaging backbone and a gateway formed when the routine is complete by way of a notifi- 
which recognises a recipient address accepts the mes- 45 cation routine. In the meantime the user can carry on 
sage. with other processing* 

A subsidiary problem resides in the existence of dif- „ cr , 1J TPXTOKr nF T Trp riR AWINGS 

ferent document formats. There are various word-proo BRIEF DESCRIPTION OF THE DRAWINGS 
essing formats in common use, various file formats and piG. 1 illustrates the overall system, 
formats specific to telex and teletex. Further features of 50 FIG. 2 is a block diagram of the hardware of one 
the invention relieve an originating access unit of any gateway of the system, 

need to worry about the format details of the message pj G 3 ^ a functional block diagram of one gateway 
recipient (although common sense must naturally be 0 f the system, 

employed— it is no use expecting a highly formatted pj GS 4^5 illustrate the transfer of a message 
word-processing file to be handled satisfactorily by a 55 between ^ different networks, 
telex recipient). Document converters for format con- nGS 6 tQ n ^ ^3 m handling a message in 
version are known in themselves and may be incorpo- more detail 

rated in the network communication system according pjQ 13 flustrates performance of two concurrent 
to the invention. ^ under GUI (general unpended interface), 

The envelope part of any protocol data unit who** 60 ^1 key to FIGS. 15, 16 and 17, 

message part consist of a document (or part of a docu- \s „ flow of routines under GUI, 

ment) includes format information identifying the docu- 'i* owl ^ 

ment format The library of specific routines of each FIG. 18 shows the structure of a GUI, 
Seway includes routes whichare responsive to re- ^^^hows-job queue ^f*£l*™> 
Saved format information to submit the message part 65 FIGS. 20 to 25 show various GUI data structures, 
automatically to the document converter when the and 

format information identifies an incompatible format FIGS. 26A and 26B show an example of usage of 
Gateways are thus free to transmit in any document GUI within the communications server network. 
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The physical location of the master document con- 

DESCRIPTION OF THE PREFERRED V erter 46 and the directory services 48 is immaterial. 

EMBODIMENT Structurally, each may comprise a database and a pro- 

This description is in four main sections: cessing facility and each may thus be physically located 

I General system description 5 in one of the gateways 12 or in a dedicated gateway. 

II Network communication The master document converter 46 implements conver- 

III General impended interface sion routines, such as are well-known per se in PC pro- 

IV Abbreviations and acronyms grams, as well as in more sophisticated applications 
It is emphasised that the whole of the description is software. The directory services 48 database may be, as 

given by way example and the invention is not limited 10 already stated, in compliance with the CCITT X500 
by any of the features disclosed, except insofar as de- Standard, hereby incorporated by reference and pro- 
fined by the appended claims. For example, GUI is vides standard database facilities for querying and 
described primarily in conjunction with a communica- searching directory entries as well as adding, amending 
tions server system but it is not limits to this particular and deleting entries. 

application. The GUI routines do not necessarily have 15 FIG. 2 shows the overall hardware configuration of a 
the structure described. The organisation of the routines typical gateway, which interfaces to a plurality of net- 
of the communications server system offers infinite works and devices. A combined telex/fax (telematic) 
possibilities for variation, and so on. Moreover the de- gateway 13E,F is chosen as the illustrated example. It is 
tailed coding of the routines and indeed the language in assumed that a plurality of computers are required to 
which they are coded are a matter of choice for the 20 handle the volume of processing and the embodiment 
programmer implementing the invention within the shown comprises three Data General MV series mini- 
context of particular hardware and for a particular ap- computers MV1, MV2, MV3, each with an associated 
plication, disk drive M » D3 storing the respective computer 

programs. The computers are connected by a high 

I GENERAL SYSTEM DESCRIPTION ^ speed laN 16, such as a standard (thick) Ethernet 

FIG. 1 shows a plurality of nodes or gateways 12 LAN or an MRC bus carrying 400 Mb/s, The comput- 

communicating with each other via a universal messag- ers are further connected via a disk controller 18 to a 

ing backbone 15 using the 1988 X400 protocol and, at bank of disk drives D4 to D8 (for example) constituting 

least in part, the X25 packet switched message transfer a disk farm 22 for molding the user data, 

protocol (although each gateway may use other media 30 The computers are connected via a terminal switch 

for part of its communication path, eg. land lines). FIG. 20 to a plurality of interlaces here shown as a telex 

1 shows eight gateways by way of example; there is in interface 14F, a fax interface 14E and a printer interface 

principle no restriction on the number of gateways. 14P. The terminal switch 20 enables the various access 

Examples of the gateways are: units to share the computer resources and moreover 

CEO gateway 12A for the Data General CEO office 35 enables two good computers to be used when one is 

automation network 13 A down and generally makes it possible to use the re- 

SNADS gateway 12B for IBM DISOSS office auto- sources in a flexible manner. In principle the invention 

mation network 13B does not require a plurality of computers and the way in 

SNADS gateway 12C for IBM PROFS office auto- which a plurality of computers is used forms no part of 

mation network 13C 40 the invention. Briefly they will be handled in accor- 

X400 gateway 12D for 1984 X400 communication dance with the known principles of multi-processor 
with X400 network 13D systems with one computer acting as master and assign- 
Fax/telex gateways 12E for communication with fax ing the activities of the others and controlling the termi- 
and telex networks 13E, F nal switch 20 and an X25 switch 32 so that the correct 

Each gateway is connected to its network through a 45 computer communicates with the correct interface for 
standard interface or access unit 14A-14F. For clarity, each input/output operation performed, also with pro- 
each gateway is shown dedicated to a single network vision for a different computer to take over as master 
and indeed such a configuration may well be adopted in under fault conditions. In a simpler system, there will be 
practice, at least so far as some gateways are concerned. one computer and the terminal switch 20 will not be 
On the other hand, a single gateway may serve a plural- 50 required. 

ity of different access units. FIG. 2 described below is a Each computer moreover has a connection to the 
combined fax/telex (telefax) gateway and, as another X25 switch 32 connected to a PDN (public data net- 
example, a gateway may be both a CEO gateway and a work) interface 34 and possibly also to a leased line 36, 
fax/telex gateway. This requires the gateway to have one use for which would be a direct connection to 
both the necessary interfaces and also the necessary 55 another gateway. The interface 34 implements the mes- 
specific routines for each type of access unit sage transfer interface ISA of FIG. 1, forming part of 

The overall system in FIG. 1 is denoted Communica- the universal messaging backbone 15. 
tions Server (CS) System 10. Each gateway 12 has an FIG. 3 is drawn as another block diagram but illus- 
interface ISA denoted MTI for message transfer inter- trates the configuration of a gateway in functional terms 
face and these interfaces communicate via the 1988 60 rather than hardware terms. If: the gateway is again 
X400 protocol as indicated by a "bus* 15B— which may assumed by way of example to be a telematic gateway 
be constituted physically by any form of communica- serving telex and fax, the actual telex and fax commuta- 
tions links. The interfaces ISA and This' 15B constitute cations will be handled by standard items with which 
the messaging backbone 15. The *bus' 15B also provides the present invention is not concerned, e.g. a Hasler 
communication with directory services 48 and a master 65 telex unit and a PC with a fax card, such as a Gam- 
document converter 46. These services, coupled with maFax CP/T card. These standard items communicate 
the messaging backbone 15 itself may be regarded as the with a network interface 14 which acts as one port of 
host 10A of the communications server system 10. the gateway and may comprise plural interfaces, as in 
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FIG. 2. Similarly, the network interface 14 might be The message is checked for validity and the addresses 
matched to a CEO network, a PROFS network, and so of the recipients are checked to ensure that the recipi- 
on. The message transfer interface 15A forms a second ents are "within" the network communication system, 
port communicating with the messaging backbone bus These procedures are well known per se in communica- 
I5B 5 tions networks. The message is then placed on a queue 

The interfaces 14 and ISA are linked by a software of messages to be processed further, indicated at 60. The 
interface 44 which is identical in all gateways. This message is acknowledged to the remote (FIT) system 
interface 44 comprises a library of core routines which 13D. 

provide communication between the message transfer FIG. 7: The message was received in 1984 X400 
interlace ISA and the software interface 44. Although 10 format and needs to be converted into 1988 X400 which 
this core library could be and is always functionally is the internal format used by the system. Trace Infor- 
equivalent to a single library it may, for convenience, be mation is added in accordance with conventional corn- 
handled as a plurality of separately maintained libraries. munications techniques. This information is used to 
In the present embodiment these comprise libraries track a message through all the systems which it tra- 
denoted TOOLS, GUI, ART. GUI represents a Gen- 15 verses. It is used to detect looping messages (they pass 
end Unpended Interface and is fully described below. through the same system twice). The message is then 
ART represents ASN.l (ISO standard) Run Times li- passed to TOOLS in the software interface 44. 
brary routines, i.e. routines for encoding data in a for- FIG. 8: The recipients are looked up in the directory 
mat in accordance with the ISO ASN.l standard, service 48 to see which gateways the message should be 
hereby incorporated by reference. These routines are 20 sent to. The originator is checked to see if he is allowed 
used by TOOLS to build PDUs, specifically 1988 X400 to use the network communication system. This use of 
PDUs. the directory service is conventional per se. 

The non-specific software interface 44 is matched to The new copy of the message is stored away (62) and 
the network interface 14 by a library of specific routines placed on the queues (64) for the other gateways. 

45. The specific routines comprise the routines neces- 25 FIG. 9: The message is now transferred to the peer 
sary at higher level to control the flow of messages, in TOOLS in the other gateway 10 (in this case Fax). This 
accordance with the nature of the gateway which they is done using what is referred to as a remote operation, 
serve. TOOLS on the other hand provides 'tools" or meaning that a command (SUBMIT— MESSAGE) and 
services common to all gateways. More specifically some data (in this case the message itself) is transferred. 
TOOLS routines impose the X400 1988 format on the 30 A sequence number is also sent over in order to prevent 
PDUs constructed by ART.send the messages, receive duplication of messages. 

message confirmations, receive messages, send confix- The message is thus now in TOOLS 44' of the FAX 
mations, handle the disk saves, submission to the direc- gateway 12E. In FIGS. 9 to 12 the elements of this 
tory service and to the document converter and may gateway are distinguished by added primes, 
perform other functions required in common by the 35 FIG. 10: The message is stored again (72). The desig- 
gateways nation of the originator is converted (CONV. ORIG.) 

The gateway communicates via the messaging back- into human readable form for use as a CSID (the string 
bone 15 with the document converter 46 and with the that appears at the top of the fax page). More call bar- 
main directory service 48. It may optionally include its ring checking is done to bar calls which are, according 
own sub-directory library 49. 40 to the directory, not permitted to the addressed recipi- 

ent from the call originator in question. 
H NETWORK COMMUNICATION The message is handed to the specific software rou- 

When a user on one network sends a message "A" via tines 45' of the fax gateway 12E. All action now takes 
the corresponding gateway to a user on a different net- place in the fax gateway 12E. 
work via the gateway corresponding thereto, the net- 45 FIG. 11: The copies of the message are generated and 
work communication system 10 converts the message stored (76) one per recipient and the dialled numbers are 
from the specific format of the source network, here formed. The format of fax addresses that are passed 
assumed to be CEO, to the different specific format of around are 9 <country code> < national number >. 
the destination network, here assumed to be PROFS. This is converted into a sequence of digits to dial. 
FIG. 4 shows the CEO network 13 A sending message 50 Each copy is now placed on a queue (78) to be sent 
"A" in CEO format to the system 10. Then (FIG. 5) the when an outgoing line (fax card) becomes free, 
system 10 converts the message to PROFS (SNADS) It will be noted that the message is repeatedly saved 
format and sends it to the PROFS network 52. to disk This is not a serious overhead because the ma- 

This process typically involves address translation, jority of the message is left on disc and the different 
handled by the directory service 48, protocol conver- 55 "saves" are effected by constructing pointers to the 
sion, handled by the specific routines 45, and document stored message proper. There is some management to 
format conversion handled by the document converter ensure that, when a copy is 'deleted', the stored message 

46. A second example will now be described in more itself is not deleted until the last user releases it. 
detail. In this example the scenario is that of a message FIG. 12: For each copy of the message, the specific 
arriving from an external 1984 X400 network (say one 60 routines 45' wait until a fax card 82 becomes available, 
provided by a FIT) and leaving via a fax card into the (signalled as an event), and then transfers the message 
telephone network. via the fax network interlace unit 80 to the fax access 

FIG. 6: The X400 network 13D opens a connection unit, i.e. PC 82 with fax card. This is a specific example 
to the 1984 X400 gateway 12D. It transfers the message of when use will be made of GUES— generic unpended 
from the PTT network to the X400 gateway 12D. The 65 event-handler service— which is discussed in detail be- 
message is then saved on to disk, namely in the disk low. 

farm 22, as indicated at 58, (so that even if the system There then takes place standard operations within the 
crashes, the message will not be lost). PC 82. The message (which is still in internal encoded 
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form) is converted into text The header is formatted is going to be spent just polling them all. What is worse, 
with dates etc in the local language. The message is traditional libraries tend to make exclusive use of shared 
then passed to the fax card. The fax card dials the num- resources, whose use must accordingly be carefully 
ber supplied and starts to transmit the message, convert- coordinated so that all the modules in the process can 
ing from text into the black and white image as it goes. 5 operate together. This would result in the modules 
At the end of the call, the fax card returns the CSID working in isolation but not when they are integrated 
(the called subscriber identification) to the PC. The fax GUI solves these problems-by taking charge of all 
gateway 12E is told the result of the transmission in- resources (timers, signals and other external events) and 
eluding the duration and the CSID. providing services which all the various libraries can 

Other operations may then take place on the fax gate- 10 use in order to access the resources in harmony. Be- 
way 12E. The message (which was still being stored) is cause GUI is the only direct user of the underlying 
retrieved to check if the originator requested any notifi- resources, there are no problems with integrating the 
cations on completion of the message (good or bad). separate modules. 

The reports are generated and handed to TOOLS for An additional benefit is that, because all external 
transmission back to the originator. Accounting records 15 events arrive through GUI (and are then dispatched to 
are now recorded on disk for charging. the various modules) there is no need to poll all the 

FIGS. 6 to 12 are concerned with the transmission of libraries continually. In met, in an application which is 
a message from the standard 1984 X400 network to a fax fully based on the principles of GUI, there is no polling 
access unit, A message passing in the opposite direction at all, because GUI automatically waits for all possible 
will be handled in a complementary or inverse manner 20 external events whenever there are no jobs to run. This 
which will be apparent from the foregoing description. results in applications which use virtually no CPU time 

when they are not processing a message. This is cer- 
m GENERAL UNPENDED INTERFACE tainly ^ ^th many traditional application archi- 

This section consists of the following chapters: tectum. 

Chapter 1- Introduction 25 In general terms, the way in which GUI works is as 

Chapter 2: Environment follows. Instead of programs being written as sequential 

Chapter 3: The User's Model code, with various calls and jumps, the main structure 

Chapter 4: Functionality of an application makes requests of service providers, 

Chapter 5: Examples of GUI Task Interactions which schedule jobs or notifications onto queues. 

Chapter 6: GUI Timers (GUTS) 30 Jobs or notifications may be categorised as follows: 

Chapter 7: GUI Event Handlers (GUES) Data returned by a service routine 

Chapter 8: GUI Specification Notification that an external event has occurred 

Chapter 9: GUTS Specification Notification that an interval of time has elapsed 

Chapter 10: GUES Specification Inter-process cornmunication (IPC), that is to say a 

Chapter 1 1: GUI Programming Example 35 message passed between two computer processes. 

Chapter 12: Internal Structure In principle there need only be one job queue but an 

Chapter 13: Data Structure Specification application can set up multiple queues with different 

Chapter 14: GUI and Communications Server System priorities and select the queues on to which it or service 

Chapter 1 Introduction providers place jobs, as a means of controlling priority 
1, 1 Outline of GUI. 40 of execution of jobs. The application (user) calls a rub 

GUI provides generic mechanisms for handling Re- routine gui— runO when it isTree for jobs to be run. 

quest/Response Interactions across an interface, exter- Gui_run0 will then run scheduled jobs off the queues 

nal events, and timers. It also provides an environment (a) in order of queue priority and (b) in first in first out 

in which applications can use impended services in order so Ear as each queue is concerned. Applications 
order to support multiple threads of processing on a 45 must not themselves pend. When an application is oth- 

single path. These mechanisms allow an entity to re- erwise idle, it should call gui-runO, with a pend option, 

quest a service (provided by GUI in the case of timers, whereby guL_run0 pends until a job is scheduled by an 

or by another entity in other cases), and later be notified inter-process communication (IPC), an event-handler 

of its completion without pending while the service service, denoted GUES below, or a tinier service, de- 
provider's routine fulfils the request. Hence the applica- 50 noted GUTS below. This assumes that, once idle, the 

tion can perform other useful processing, in parallel process has nothing further to do until an IPC or exter- 

with the service provider's processing of the unpended nal event arrives or a timer goes off. This is the situation 

request which obtains with a communications server system 

In a complex product such as a communication server where activity is initiated in response to events, such as 
system there are inevitably many separately designed 55 "message coming in", "fax card ready" and so on, or at 
modules, all providing service interfaces to their users timed intervals. Such events are what might be termed 
and all of which must coexist peacefully. The traditional hardware events, signalled by a change of logical state 
problem is that each module has its own set of rules and on a handshaking line, for example. IPCs can be re- 
restrictions which its user must conform to and there garded as software events. 

may be incompatibilities between the requirements, 60 Input events are represented by calls to user routines 

which take much effort to resolve, when all the modules with specified parameters, which can indicate the event 

are put together, with a high risk of bugs being left in that occurred. These events are placed on the queues by 

the system. 08115 to guL-scheduleO and picked up by the mam task 

For example, a library which needs to wait for exter- when it calls gui_run(). External events are not the 
nal events niight traditionally have had a routine which 65 only things which can be scheduled with GUI. Un- 

the application must poll from time to time to see if pended request completions are another obvious class 

anything had happened. This is perhaps tolerable with of user routines which can be scheduled and any rou- 

one library but with say a dozen libraries, a lot of time tine, whether library or user, running within the mam 
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task can schedule any general processing which it needs 
to do and this will get run some, time later. 

When an application is doing its own processing it 
must return to guL-runO sufficiently frequently to 
avoid disruption of the system, eg. by causing timer 
inaccuracy or affecting network usage or user response 
times. The application may be said then to poll GUI but 
it is important to recognise that it only has to poll the 
one "event handler", not many handlers as in the con- 
ventional approach. 

The application m?»i task allocates a queue, denoted 
by a queue identifier or quid, for each level of priority 
which it requires. When library routines are called they 
have to be told the quid onto which they must schedule 
their jobs. In general, external events will be given high 
priority quids while general internal processing (espe- 
cially that involved in housekeeping and accounting 
operations) can be given low priority quids. 

The structure of an ideal application can be expressed 
as the following outline of a main routine: 



{ 



} 



initialise self; 
initialise GUI; 

allocate quids, for required priorities; 
initial'*"" all libraries; 

maybe schedule initial jobs and start any regular timers; 

do forever 
gui_run(PEND) 



The significance of the pend option for guL-run will 
be explained below, section 4.1.4. 

All of the external event processing and internal li- 
brary processing gets done as scheduled jobs out of the 35 
call to guL-runO- External events are being scheduled 
by GUES and in response to IPCs. Internal library 
processing gets scheduled either out of the initial im- 
pended request routine or out of jobs run because of 
external events destined for internal service providers, 40 
denoted GCSP's below. In this ideal example, all of the 
application's own processing gets run as scheduled jobs. 
This requires the application to schedule the first job or 
jobs it needs to do before it calls guL_ran() and it can 
always schedule further jobs at later times. This stnio 45 
tore has the advantages that the process automatically 
sleeps within guL-mn() when there is nothing to do and 
that the application code is integrated into the GUI 
mechanism- However the invention also optionally 
provides "wakeup" routines which enable a user rou- 50 
tine to wake up pended gm runQ and enable GUI to 
wake up an idle user loop, as explained below. 
1.2 GUI and the operating system. 

GUI makes it possible to write applications in such a 
way that they are portable between apparently incom- 55 
patible operating systems such as VS and UNIX. What 
is said about UNIX applies in essence to MS-DOS, with 
the difference that MS-DOS uses real, hardware inter- 
rupts whereas UNIX uses software interrupts (signals). 
The fundamental difference between VS and UNIX is 60 
that VS processes are multi-threaded while UNIX pro- 
cesses are not. Under VS there can be multiple threads 
(VS tasks), all executing apparently concurrently 
within the same process address space. On the other 
hand, under UNIX there is only one thread running in 65 
a process, although it can host another interrupt-level 
path by the use of software interrupts. However VS 
does not have a documented mechanism for software 



interrupting the main task of user processing, in contrast 
to the UNIX routine killO- Under VS an application 
uses a dedicated VS task to await external events. 
In spite of these incompatibilities an application writ- 
5 ten within GUI can run under VS or UNIX, provided 
that the features particular to the two operating systems 
are not used. Thus no use must be made of VS multiple 
threads by the GUI user and no use should be made of 
UNIX interrupts. On the contrary, the application must 
10 be written with a single main task and interrupts or 
events must be handled by. the event-handler services 
within the GUI framework. 

In writing "server" applications, such as a network 
communications server, it is highly desirable to be able 
15 to process many items (messages) in parallel within a 
single process, since so much time is spent waiting for 
events, during which time efficient use of resources can 
be made by processing other messages. GUI provides 
an environment which can handle this requirement and 
20 which is the same regardless of the underlying operat- 
ing system. Known application packages which use 
resources efficiently to process multiple messages are 
specific to one operating system. A specific example of 
how GUI is used within the communication server 
25 system described above is given in Chapter 14 of this 
description. 
1.3 Terminology 

GUI typically provides an interface between a li- 
brary, written by one set of programmers to provide a 
• 30 service, and some user code, written by different pro- 
grammers to make use of the service. Such library code 
which uses GUI is called a GUI-Conformant Service 
Provider (GCSP). The user code is called, simply, The 
User. 

Throughout this description, routines provided by 
GUI will be indicated by names beginning "gui—" (e.g. 
gui— schedule). Routines provided by a GCSP will be 
indicated by names beginning -GCSP—", whilst rou- 
tines written by a User will begin "user_". 
Following is a list of terms jased in this disclosure: 



Pend A routine pends if its processing path comes to a hah, 

whilst awaiting an external event For example, 
many VS system calls cause the calling task to pend 
while the call is run on a VS path. 

Unpended A routine which does not pend while awaiting 
external events is said to be unpended. 

Task A thread of processing, which is logically separate 

from threads performing other processing. 

Main Task The processing thread within a process. 

Path A thread of processing, which is physically separate 

from threads performing other processing. Paths 
may be Parallel, as in the case of multiple VS-Tasks, 
or Nested, as in the case of a base level path and an 
interrupt level path. 

VS-Task A path, in the above sense, which is a physically 
scheduled entity, created by a 7TASK system call, 
under the AOS/VS operating system. 

GCSP GUI Conformant Service Provider. A library which 
provides a service conforming to the GUI rules 
and formats. 

User Code which makes use of GUI, in order to request 

services of a GCSP. 



Chapter 2 Environment 
2.1 Hardware and OS Environment 

An aim of GUI is to provide an interface which is 
moderately independent of the OS and Hardware envi- 
ronment This means it must work under AOS/VS on 
an MV, MS-DOS on a PC, and UNIX on an MV or 
other hardware, for example. 
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MS-DOS and UNIX are single-threaded. This de- 1) It may set up an interrupt handler, which saves the 

scription speaks of multiple tasks, with one or more input character each time a keyboard interrupt 

main tasks, and some event wait tasks. In the MS-DOS comes in, until a line is available, 

and UNIX environments, this terminology equates to a 2) It may spawn a process which will do a pended 

Base Level "main task", and a set of Interrupt Level 5 read, and signal the main process when a line of 

service routine "tasks". Although GUI allows a user to input has been received. 

have several "main tasks", it should be noted that this 3 ) It may spawn a task, which does a pended read, 

feature is not available under MS-DOS or UNIX. It is and calls the _ 

recommended to have only one main task, even under Notification routine when the input is complete. 
AOS/VS, due to the possible requirement for a future «> Wndrt these are just some of the poMUrti* (1) is 

port to another OS. The possibihty of having multiple typical for MS-DOS, (2) foj UNIX, and (3) for VS. 

main tasks is intended to^st programmed who are <** the request routme has returned, the User can 

converting existing multiiasked programs to use GUI. perform any further processing 132 it has to do but such 

Whateve7 the physical environmeToUI is con- processing must mclude periodic calls to gm- 

ttrtnd to run £ a^ngle address space. It does NOT 15 r™0- ^^Z-^^W, ^ Z°^l 

■ . , i . mor (or "tasks ) established for this user, n) the mam 

provide an mterface X, and 0Q the request processing task 134, which 

rateaddress spaces, for example in two different VS or ^ ^ g ^ ^ ^ procesSj 

UNIX processes. 0 r in a separate VS-style task. When the request task 

2.2 Language Bmdings detects the completion of the request (Le- when a line of 

Forreaso^ofeffici^ 20 J^^La received as indSLd atl35), it calls(13<0 

standard GUI library is designed to be caUed with C ^ chedul e to place ^ Vsefs Notification routine 
calling conventions (Le. call by value). GUI calls all m ^ a ^ ^ result of ^ request (a ^ 0 f 
user-supplied routines with this same convention. . t). When gui_runO is next called, as indicated at 

Under AOS/VS, languages such as PL/I use a call- %$ 138> ^ notification routine is taken off the quid and the 
by-reference calling convention, called the External user processing task has acquired the line of input which 
Calling Sequence (VS/ECS), which is incompatible ft ^ggg^ 

with the C calling convention used by GUI. This means It ^ OTnveni ent to say that the notification routine or 
that GUI cannot be called directly from PL/I, and that j Qb fc put on to md off a quid what is actually put 
PL/I routines cannot be scheduled using gui_sch- 3Q Qn t0 ^ quid ( even more precisely on to the queue 
eduleO- identified by the quid) is the address of the notification 

If the need arises, a PL/I version of GUI could be routine and any arguments for this routine, as subse- 
implemented, by adding a thin layer of C code on each q ue ntly explained with reference to FIG. 24. In the case 
side of GUI. One layer would provide ECS-callable 0 f -piQ ^ ^ arguments are characters of the input 
routines, which convert the parameters, and then call 35 

the standard GUI routines. The other layer of code Whilst all of this example can be achieved without 
would be required for any PL/I routine which needs to qtjt^ om er cases may not be so simple. In any case, 
be gui_scheduledO, and would consist of a C routine GUI provides a framework which aids both the User- 
which is actually scheduled, and which then calls the writer and the GCSP-writer in implementing such 
PL/I notification routine with the modified parameter ^ mechanisms, in a way independent of the operating 
format system which is used. 

Chapter 3 The User's Model .Chapter 4 Functionality 

The model of a GUI user is an entity (some user-writ- This Chapter starts by describing the routines pro- 
ten code) which wishes to make requests of a Service vided by GUI, in order to support an impended envi- 
Provider, in an impended manner. 45 ronment It then goes on to describe the routines re- 

To make a request, the User calls a routine which quired of a GCSP, and GCSP User, in order to support 
specifies the service which it requires. Since the actions an unpended interface, 
required to implement the request may be lengthy, the 4.1 GUI Provided Routines 

user does not want to wait for the completion there and The library portion of GUI (as opposed to the Rules 
then, but rather, wants to be told when it is complete. 50 governing its usage), provides a mechanism for schedul- 
This is the basic concept of an unpended request ing arbitrary user routines, for running at a later time. 

The way in which the User is told of the request's The generic term used for one of these scheduled rou- 
completion, is by a user provided Notification routine tines, is a Job. 

being called, usually by GUI. GUI provides a routine for queuing up Jobs (gui- 

3.1 Unpended Request Example 55 -schedule), and a routme to be called when a user is 

Consider the following example, which is illustrated ready to run these Jobs (gui run). For additional flexi- 
in FIG. 13. A User 130 wants to read a line of input bility, GUI supports multiple queues of Jobs, which can 
from a keyboard, but does not want to pend if input is have different priorities associated with them at alloca- 
not yet available, nor repeatedly poll for the arrival of tion time. 

input This functionality can be satisfied by an unpended 60 4. 1 . 1 GUI Imtialisation Gui initialise 0 
request, provided by a GCSP. This routine takes no parameters. It should be called 

The GCSP writer provides a Request routine 131, say by each component (Le. each GCSP and User), before 
"GCSP— get-JineO", which takes as an argument the any other GUI routine is called. GUI ignores all but the 
address of a User notification routine 137 to be called first initialisation, 
when the input is available. The Request routine initi- 65 4.1.2 Queue Allocation 

ates the service and then returns, without pending. As mentioned above, GUI provides multiple queues 

There are many ways in which the request may be of scheduled Jobs. This enables Users to specify the 
initiated by the GCSP Request routine: relative priorities of Jobs, and to collect Jobs which 
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form logical classes onto a queue which is separate from Jobs which are scheduled on queues owned by that 

other logical classes. Each GUI queue has a QUeue thread: 

IDcntifierWUID), which is assigned by GUI, when a gui-run (flag) where the arguments are asfoUows: 

nueue is allocated- * Aag-The flag says whether or not GUI should 

JK^SS (priority, user-wakeup. quid-ptr) 5 pend the thread, if there are no scheduled routmes 

The parameters to this call are as follows: J° Txm - . , 

•prio^pedfiesthe^ 

routine, which GUI will ^ wh = there are 10 in J™ to NOPEND, then GUI will check for 
Jobs available for wnms on this queue. «J£ & ^ immG ^ iy if none is 

* quid-ptr-GUI ffls in this parameter, with the *™^ r ^ e roudnes to ^ then GUI will run 
queue identifier wiuch it assigns to tins queue. JJJ * *** ^^return. lvalue returned from 

Each queue which is allocated has an Owner which is ^ ^^Q^tL^ whether or not a job was run. 

thepathwrJchaUocatedit If flag' is set to PEND, then GUI will pend the call- 
Under VS, there could be multiple paths (VS-Tasks) ^ ^ ^ ^ a routme ready to run. After 

capable of allocating GUI queues, although this is not which become ready , GUI pends 

recommended, for reasons of compatibihty explained ^ ^ ^ m0fe 

above. Under single-threaded operating systems, only ^ 4 ^ control 

the main thread is allowed to allocate queues (ue. they * m ^ penned case, GUI would never return 

may not be allocated from interrupt level). from gm _ run# another routine is provided which the 

Any path may schedule Jobs onto any queue, how- u$er ^ call m or< jer to force a thread to return, if 

ever, only the owner can run Jobs off that queue. This necessar y ; 

will be described further under the section on 'gui- 2J g^^gup (quid) 

—runO*. This wakeup routine does not pend. Hence, it can be 
4.1.3 Job Scheduling called from any path, including from a Job which is 
GUI provides a routine, which Users and GCSPs can n^ning 0 n the specified quid. This call will 
call, in order to cause a specified routine to be called, caaBt ^ path owns the quid, to return from < 
with given arguments, and (for VS) on a particular task: 3Q gT j mn at ^ fi^t opportunity (ie. immediately, if it is 
guL~schedule (quid, routine, argl, arg2, arg3, arg4) pen( ied awaiting Jobs or when the current job corn- 
where the arguments are as follows: pletes, if one is being run). Using the pend/no-pend 

* quid— The queue onto which 'routme* should be option of guL_run, the User has the choice of either 
scheduled. pending within GUI whenever it is idle, or else polling 

* routine — A pointer to the routine which GUI 35 f or notifications to run from its own idle loop, 
should call. As an additional option, in the case where the User 

* argl . . . arg4 — Arguments with which to call *rou- prefers not to pend within gui-run, it may supply a 
tine*. wakeup routine for GUI to call, whenever GUI re- 

This GUI routine does not pend, and as a result of this quires control of a thread, in order to run a Job on a 
call, GUI will call 'routine', when the owner of the 40 quid owned by that thread: 

specified queue calls gui-run. The routine will be user— wakeup (quid) 

called thus: The address of this routine is specified as a parameter 

(♦routine) (argl, arg2, arg3, arg4, quid) to guL-allocate— quid, for each quid allocated. This 

The 'argN* parameters can each be big enough to mechanism gives the user the option of not polling for 
contain a pointer (32 bits on an MV, 16 or 32 bits on a 45 notifications to run, but of being told when they are 

PC), however, GUI does not indirect through them. available. In this case, whenever GUI calls 'user—- 

Hence the parameters may be used to pass either inte- wakeup', the User must call 'gui-run*, with the speci- 

gers, or pointers, as required. In the latter case, the fied task, in the near future, i.e. as soon as it is in a posi- 

caller of gui— schedule must ensure that the pointer tion to do so. 

remains valid, until the scheduled routine has actually 50 Ideally GUI is programmed using only the gui—sch- 

been run. GUI will only copy the values of the argu- eduleO and gui— runO routines. However the optional 

ments themselves between stacks, and not anything wakeup routines can be valuable, since they enable 

they might point to. Users with different tasking structures to use GUI in the 

The 'quid* identifies a particular GUI queue, onto way most convenient to their own requirements. For 
which the Job should be scheduled. This provides con- 55 example gui— wakeupO can be useful in implementing 

trol over the relative priorities of scheduled Jobs, and user interface programs, e.g. adding entries to the direc- 

determines the sequence in which Jobs will be run when tory of the communications server system. Specifically, 

the owner calls gui-run. gui-wakeupO may be called when returning from the 

In a VS environment with multiple main tasks, the GUI environment to a more conventional one (handling 
quid also provides control over which VS-Task the Job 60 the user interface) when On this example) a directory 

will be run on. Note, however, that this is not a reconv request completes, 

mended configuration 4.2 GCSP Provided Routines 

4.1.4 Running Jobs This section describes the routines which a GCSP 

In order for GUI to be able to run a Job which has must supply, in order to provide an impended service 
been gui-schedule'd, it must be able to gain control of 65 across GUL 

the thread owning the queue onto which the Job was A GCSP provides Request routines, to be called by 

placed. For this purpose, GUI provides a routine which the User, in order to initiate the services which the 

a user can call from a main thread, in order to run any GCSP provides. 
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Each of these Request routines, must obey the fol- 4.4 Queuing of Scheduled Notifications 

lowing rules: On a per-quid basis, GUI guarantees to run any 

* It must not pend. queued Jobs in the order in which they were scheduled 

* It must arrange for a User-supplied Notification There is no sequencing enforced between separate 
routine to be called when the request is complete. 5 quids. If there is a Job scheduled to run on a particular 

To prevent problems of stack run-away, and to avoid high priority quid, and the User calls gui— run with the 
the user's notification routine being called before the path which owns that quid, then GUI will run that Job. 
request routine returns, the GCSP must NOT call the This will happen regardless of the fact that notifications 
notification routine directly from the request routine. It may have been queued on other lower priority quids, or 
is permissible, however, for a GCSP to call the notifica- 10 even on higher priority quids which are owned by an- 
tion from one of its own routines, which it has previ- other path, for longer. 

ously scheduled. Chapter 5 Examples Of Possible GUI Task Interac- 

* It must provide a mechanism by which the User can tions 

specify, if it so requires, onto which quid the Notifi- Any GUI user has one or more <t main tasks", where 
cation routine should be scheduled. These require- IS a main task is defined to mean a path which does user 
ments can be satisfied, by the GCSP User specify- processing, and is allowed to own GUI quids (i.e. it 
ing a Notification routine, to be called on comple- excludes event-wait-tasks and interrupt handlers) . Al- 
tion of the impended request, and a GUI quid, onto though a main task may perform lengthy operations, 
which the GCSP can schedule the notification. and even pend on operations such as disc I/O, it is not 
In the case where the service provided by the GCSP 20 advisable for a main task to pend on a potentially infinite 
is strictly of the Request/Response type, a typical Re- wait (e.g. pended, non-timed-out, terminal I/O). Failure 
quest routine may be of the following nature: to observe this advice may result in severe disruption of 

GCSP— Request (Nfunc, quid, argl, . . . argn). where the entire GUI environment, since it may become im- 
the arguments are as follows: possible for GUI to 'wake up' a main task, in order to 

* Nfunc— Pointer to the caller's Notification routine. 25 run a notification. 

* quid — A GUI quid, onto which *Nfunc* will be As described in Section 4.1.5, there are two basic 
scheduled. methods of thread control provided by GUI, supported 

* argl . . . argN— Additional arguments, specific to by the 'flag' on the call to gui— run. This section de- 
request, scribes possible uses of these mechanisms, and illustrates 

If the GCSP so decides, then it may use any other 30 the inter-task relationships for each, 
mechanism it likes for specifying 'Nfunc* and 'quid' (&g. The two mechanisms are distinguished by the loca* 
they may be hard-coded, or decided at initialisation toon of the idle "wait-point", either within GUI, or 
time). In particular, the interactions across the interface within the User, 
need not be strictly of the Request/Response nature, 5.1 Wait point within GUI 

since the GCSP can, at any time, schedule any user 35 This mechanism is supported by two calls to GUI 

routine to be called. routines: 

4.3 User Provided Routines * gui-xun (pend); 

As indicated above, the User supplies Notification * guL_wakeup (quid); 
routines, for all requests it makes. These are the routines The user calls gui— runO on its main task thread, and 
which will be called, in order to inform the user of a 40 with the pend option selected, when it is idle. When a 
request's completion. At some time after the User calls Job becomes available, on a quid owned by the calling 
the GCSP Request routine,, either that routine, or else path, GUI will call the scheduled routine, from gui- 
some other GCSP or GUI routine, will call the User's —run. 

Notification routine (Nfunc, in the above example). If the user needs to regain control of its main task 

This Notification routine must obey the following 45 thread (either because another task of its own, or a GUI 
rules: Notification call, has queued some work for it), then the 

* It must not pend. user can call guL-wakeupO, which will cause guL_run 

* It must be prepared to be called on any path, unless to return to the main task as soon as possible. 

it has arranged otherwise with the GCSP (eg. by If the user needs to control the threads of more than 
specifying a quid onto which, the notification 50 one main task in this way, then the 'quid' argument can 
should be scheduled). be used to uniquely identify the owning path. 

* It must not call gui_run(). In order to prevent prob- FIGS. 15 and 16 illustrate the flow of control, and 
lems of stack run-away, calls to gui— run may not task interactions for this mechanism, using the conven- 
be nested. tions set out in FIG. 14. Thus FIG. 14 shows three 

Considering the example Request routine above, 55 different kinds of box used to denote GCSP routines, 
where the GCSP uses GUI to schedule the User notifi- USER routines and GUI routines and the mranings of 
cation routine directly, that routine would be called the left, right and down axes, namely CALL, RE- 
thus: TURN and TIME respectively. Note that these figures, 

(•Nfunc) (argl, arg2, arg3, arg4, quid); where the argu- and the descriptions below, assume there is just one 
ments are as follows: 60 main task. The underlying mechanism is not affected by 

* argl, . . . arg4 — Arguments specific to Notification. this assumption but it simplifies the discussion consider- 

* quid — The GUI quid on which *Nfunc I is being ably. 

called. Pended gui run, resulting in User Notification 

No use can be made of a return value from Nfunc, FIG. 15 shows the use of the pended gui_ runO rou- 
since it may not be called directly from the GCSP, nor 65 tine, resulting in GUI calling a GCSP notification rou- 
on a stack which returns to the GCSP. Unless the User tine, which has been scheduled to run on this task, 
has arranged with the GCSP, for Nfunc to be called on Proceeding from the top of the diagram downward, 
a specific quid, it may be called on any path. the user starts by doing some of its own processing on 
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the main task thread 150. During user processing 151 uled Job on a given quid, it will call the user_wakeupO, 
the user makes a call 152 to a GCSP Request Routine, which was supplied when that quid was allocated- GUI 
shown here as GCSP-Request 153. This routine does will only run Jobs, on the thread of the main task which 
some processing, perhaps initiating some activity, and owns the quid, onto which the Job was scheduled 
then returns. 5 Note, that although the user_wakeup routine is con- 
When the user is otherwise idle, it calls guL-runO 155 sidered here as a single named routine, the actual rou- 
with the pend option, i.e. guL_run(pend), in order to tine to call is specified as a -parameter to the gui_al- 
give control of the main task thread to GUI. Iocate_quid0 call. This allows the user to specify dif- 
Within gui_run0» GUI checks for any notifications ferent wakeup routines for different GUI queues, which 
to run, and, assuming there are none, waits to be poked 10 may be useful where there are multiple separate User 
by either gui— schedule, or gui_wakeup. Some time entities, in a single process*, 
later, a path 156 initiated by the GCSP receives an Unpended gui run, initiated by user wakeup 
incoming event Simple examples of events are "key FIG. 17 illustrates the use of the unpended version of 
pressed", "printer ready", "disk drive ready" and so on. guL-run and its interaction with the user-wakeupO 
Within the context of a communications server system 15 routine. It shows the user making a GCSP— requestO 
other examples are "message coming in", "network 170 on its main task thread, and then entering a notional 
ready", "network wishes to send" and so on. Alterna- idle loop 171 (so long as the main task has a means of 
tively the event may be an IPC. The path 156 handles periodically checking for user_wakeup, there is no real 
the event (157) and, because of the GCSP request, need to have an explicit idle loop), 
knows that it now has a Notification to run on the main 20 Some time later, an event arrives, which awakens a 
task. It therefore calls gui_schedule 158, which queues GCSP event handler 172 task. The task starts to service 
up the routine to be run, and sends an inter-task message the event, and in this case discovers that there is a Corn- 
to the main task, which is still waiting inside guL_run0. pletion Notification to run on the main task. It therefore 
Having handed responsibility for the event to the main calls gui-schedule 173, which queues the Notification 
task, guL-schedule returns to the GCSP event handler, 25 internally, and calls the user_wakeup routine 174, for 
which, it is then assumed, goes back to waiting for the quid in question. 

another event This user-provided routine takes some action, which 

The main task now wakes up, within gui_run, and will cause its main task to call gui-xun. The exact form 
seeing there is a notification to run on one of its owned of this inter-task message is a user issue. The user- 
quids, calls the GCSP Notification routine 159 for the 30 wakeup routine then returns to the service routine, 
scheduled call. Once the Notification returns, guUrunO which in turn goes back to waiting for another event 
goes back to waiting to be poked again (155'). At some time in the near future, the user's mam task 
Pended gui run, interrupted by gui wakeup picks up the inter-task message sent by user_wakeup, 

FIG. 16 shows the use of gui_run(pend) 160 in the and as a result, calls gui_run0 175 in order to give 
main path, with the user of another path calling gui- 35 control of the main task thread to GUI. 
_wakeup0 in order to regain control of the main task Within gui_run0, GUI scans its queue of Jobs wait- 
thread, ing to be run, until it finds one to run oa a quid owned 

Having called gui-xunO with the main task during an by the calling path. When it finds one, it calls the appro- 
idle period, another path receives some event, the pro- priate user Notification routine 176. When the Notifica- 
cessing 161 of which requires the user to knock its main 40 tion routine returns, GUI completes its internal process- 
task off the pended guL-runO- ing, and then returns from guL-run, handing control 

This other path, (which may be a GUI wait task back to the user 177. 

executing a user notification routine, or else any another Chapter 6 GUI Timers 

user path), calls gui_wakeupO 162, causing GUI to This chapter describes the Generic Unpended Tmier 

release the main thread, and return from gui_run(). The 45 Service (GUTS), which provides a mechanism for 

user is then free to do any processing 163 it likes on the scheduling unpended timed events. Note, that this is not 

main thread. When such processing is complete, and the an integral part of the GUI environment. Rather, it is a 

User is idle, it calls gui_run0 1« once again. GCSP, which happens to be supplied as part of the GUI 

5.2 Wait point within User library. An understanding of this particular service is 

This mechanism is implemented by a User-provided 50 not necessary in order to understand GUI itself. The 

routine, and the gui-xunO routine, with the nopend Timer Service consists of a series of GUTS-provided 

option- Request routines, and a definition for a User-provided 

* user— wakeup (quid); Notification routine. The following sections describe 

* gui— run (nopend); these routines. 

The User can do anything it likes in its main task idle 55 6.1 GUTS Provided Routines 

loop. The User can either poll guL-run periodically, This section describes the routines provided by the 

specifying that GUI should not pend if there are no calls GUTS, in order to start and cancel timers. A formal 

scheduled, or it can wait for GUI to indicate that it interface specification is given in Chapter 9. 

wants control of a thread. The former alternative is 6.1.1 guts_start_timer0 

what was illustrated in the example of FIG. 13. In the 60 This routine is called to schedule a timer to go off, 

latter case, GUI will call the user_wakeup0 routine after a specified delay has elapsed. It conforms to the 

when it wants the owner of a quid to call guL-run. The generalised GCSP Request routine format, as described 

User must then call gui-xunO in the near future, in in Section 4.1, and takes the following arguments: 

order to give control of the main thread to GUL Typi- * Nfunc— Pointer to the user's notification routine, to 

cally, GUI will run a Job, and then return from gui- 65 be called when the timer expires. 

_ run Q * quid— The GUI queue, onto which Nfunc should 

The 'quid' argument allows for the control of more be scheduled. If the value NULL-QUID is speci- 

than one main thread. When GUI wants to run a sched- fled, then the notification will be called directly 
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from lie path which detects the expiration (this 
will be a separate task under VS, and an interrupt 
handler under UNIX or MS-DOS). 

* delay— A positive delay, in seconds, relative to 
now. 5 

* user— ref— A user reference (typically a pointer to 
some user control block). 

* timer_name — A number, cUstinguishing this timer, 
to the user and GUTS. 

* user— argl — An argument, for the user's benefit, 10 
which will be passed back on the call to the notifi- 
cation routine. 

user— arg2 — Another user argument, as above. 

An instance of a timer is uniquely identified by the 
user-reference/timer-name pair. For example, if the 15 
user is implementing some networking protocol, the 
'user— ref might be a pointer to a control block for a 
particular connection, and timer— name* might indicate 
the event being timed (e.g. connection-timeout, clear- 
timeout, eta). 20 

The *user ref and timer-name*, will be specified as 
parameters to the user notification routine *Nfunc', 
along with *user_ argl', and *user— arg2\ 

GUTS timers are one-off events. Once a timer has 
expired, and the user's notification routine has been 25 
scheduled, that timer no longer exists. If the user re- 
quires a timer to go off at regular intervals, a new timer 
should be started from the notification routine. 
6. 1 2 guts, cancel— timerQ 

This routine is called to cancel a previously started 30 
timer. It takes the following arguments: 

* user ref— The user reference, specified on the call to 
guts. ..start— timer. 

* timer name — The timer name, specified on the call 

to guts— start— timer. 35 

* remain— ptr — GUTS fills in this parameter with the 
number of seconds remaining before the timer 
would have gone off. 

6. 1 .3 guts check timerQ 

This routine is called to check how much time re- 40 
mains before a timer will go off. It takes the same argu- 
ments as guts— cancel— timerO, but the timer is not can- 
celled. 

6.2 User Provided Notification Routine 

As shown above, the caller of guts— start timer pro- 45 
vides a notification routine, 'Nfunc', which will be 
called when the timer expires. If we call this routine 
'user— timer-expired', then it will be called as follows: 
user— timer— expired (user— tel, timer— name, use- 
r— argl, user— arg2, quid) where the arguments are 50 
those specified on the original call to guts start timer. 

6.3 Timer Accuracy 

The accuracy of the Timer Service, will be such that 
timer expirations will be scheduled within + 1 second of 
the intended time, when running on a normally loaded 55 
MV with no memory contention. However, since 
GUTS uses GUI for Notification scheduling, the exact 
time at which the Notification will be run, depends on 
the number of GUI notifications currently scheduled, 
and on how soon the User calls gui— run. . 60 

Chapter 7 GUI Event Handlers 

This chapter describes another GCSP, which may be 
included in the GUI library, namely the Generic Un- 
pended Event-handler Service (GUES). Like the timer 
service, this service is not an integral part of GUI itself. 65 
It will be a frequent requirement for GCSP's to set up 
event handlers, in order to wait for the completions of 
actions which they initiate. Such handlers are environ- 



ment-specific. Under AOS/VS, they may be VS-style 
tasks, whilst under UNIX, they will clearly not be. 

For this reason, and since many Users may require 
the same services, GUI provides an event registration 
service, which attempts to hide the details of the wait 
tasks from the User. Clearly, the User will be aware of 
the environment, to the extent that it must tell GUI 
what sort of event to await, but this awareness is con- 
fined to the selection of a type of event on an interface 
call. There is no need for a User to know the details of 
spawned VS-style tasks, or of Interrupt Vectors, or 
whatever the underlying mechanism is. 

Note that in the context of this service, a "User" may 
be a GUI User, or another GCSP. They are both just 
"Users", as far as the GUES is concerned. 

GUES is available only under the AOS/VS and 
UNIX operating systems. The actions required on re- 
ceipt of MS-DOS hardware interrupts are too special- 
ised to be handled by a generic service such as GUES. 
MS-DOS programmers requiring this sort of functional- 
ity will write their own application-specific Interrupt 
Service Routines. From these ISR's, they can take 
whatever action is necessary to dismiss the interrupt, 
and call gui— schedule Q ul order to pass the event to die 
main part of the application. 

7.1 GUES Provided Routines 

In order to register an interest in a class of event, a 
GUI user calls the GUES routine: 
gues— subscribeO 

This routine take the following arguments: 

* quid — The quid on which Nfunc should be sched- 
uled. 

in— pars — This structure contains an indication of the 
type of event being subscribed to, and any addi- 
tional parameters required for that particular sub- 
scription (e.g. signal number). 

out—pars — GUI returns a subscription id, and any 
event specific information in this structure, type, 
etc.) 

When GUES receives an incoming event, it scans its 
queue of subscriptions for that event, and schedules the 
notification routine of each. Note that there may well be 
more than one notification routine registered for a given 
event, particularly in the case of signals. 

GUES will take the approach of calling all relevant 
notification routines, rather than allowing the notifica- 
tions to accept or refuse an event This is less prone to 
loss of events due to user error. 

The following events will be amongst those available 
for registration: 

* ?SIGNL/s (in AOS/VS) 

* Software interrupts (signal(2) in UNIX) 

* Child process terminations. 

* AOS/VS Connection Breaks (simulated as obituar- 
ies by GUES). 

* Unix I/O readiness, as indicated by select(2). 
The exact parameters required for each of these 

events, are specified in the GUES interface specifica- 
tion (Chapter 10). 

7.2 User Provided Routines 

The User of this service, must provide the notifica- 
tion routine Nfunc If we call this routine 'user— even- 
L_occurred', then the call has the following form: 
user— event— occurred (sub— id, event-type, udata, 
event— param, quid) where the arguments are as fol- 
lows: 

* sub— id— The subscription id returned by GUES on 
the gues— subscribe call. 
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* event-type— The type of event, as specified to nals such as SIGPOLL are of use in interfacing to Ker- 
eues-subscribe 0- nel services. 

* udata-User data; as specified in in_pars to gues_ The same warnings and precaubons apply as for 
subscribe ft AOS/VS ?SIGNL events, above. Additionally, users 

* event-param-This argument conveys information 5 should NOT define their own i agnal handlers, since 

SSe event bJnJnotified. (e.g. For obhu- th«e ^ tSi^^f 
ana, it contains the PID and eat status of the subscribers, with impredictoWeresults. 

• «T Users should also refrain from subscribing to SI- 

. 5CSSSS3. - ~~ * u io oug. -at 

rence are specified in Chapter 10. This subscription allows GUES users to be notified of 

7.3 Event Concepts and Warnings process tenmiiations, and for AOS/VS, cus- 

This sectiondescribes the concepts associated wrth ^/^e^o^eaks. Each subscriber re 

each of the GUES event subscriptions, and warns about ^mer/^ for ^ which spedfies 

any restrictions implied by their use. ^ id ^ exit status of ^ terminated process. 

7.3.1 AOS/VS ?SIGNL Events Un(jer A0S/V S, GUES establishes a separate task to 

This subscription allows GUES users to be notified ^ repeated ?ireC , s on the system port for termmation 

upon receipt of AOS/VS Fast IPCs , (?SIGNL). 2Q messages (?SPTM). Users should not do their own 

GUES establishes a single AOS/VS task to be shared 7r j££g s on ^ ^ they will disrupt the GUES 

by aH 7SIGNL subscribers, which is dedicated to doing $erAct Under UNIX, GUES subscribes to its own 

7WTSIG calls. The Unique Task ID of this task is re- signal(2 ) service, with a signal number of SIGCLD, in 

turned to each subscriber as output from the gues_sub- Qrder tQ be notified G f child terminations. When a notifi- 

scribe call, and can be used by an application as a pa- 25 ^ receivedj GUES does repeated wait3(2) calls 

rameter to a 7SIGNL system call. ^ WNOHANG option, to collect termination 

By passing the 7WTSIG task UED to another process, information for all expired children. Users should not 

this GUES service can be used to support a Fast IPC ^ wa j t (2) Q r wait3(2) themselves, as this will disrupt 

mechanism, with no direct data transfer. This is useful ^ ques service for all subscribers, 

in conjunction with a shared memory scheme for data 3Q 7 3 4 Unix s e lect(2) Events 

transfer, or in interfacing to impended Kernel service Thi s subscription allows UNIX users to be notified 

such as 7QNET. when an I/O condition exists on one of a specified set of 

There are two problems associated with 7SIGNL file descriptors, 

events: The Unix select(2) system call takes 3 bit array argu- 

* Anyone can send a 7SIGNL to your process, with- 35 mentSj readfdsQ, writefdsQ, and exceptfdsQ. Within 
out any validation being done. each of these arrays, each bit represents a defined file 

* ?SIGNLs do not nest, so they may be lost if they are descriptor. The readfdsQ mask specifies file descriptors 
not processed fast enough. on which the caller is interested in doing read(2) calls, 

The following precautions overcome these problems: tbe writefdsD mask specifies those on which the caller is 

* Never assume that a 7SIGNL notification was in- 40 interested in doing write(2) calls, and the exceptfdsQ 
tended for you. It may be for another GUES sub- mask specifies those on which" the caller is interested in 
scriber, or it may have been sent by the PMGR, or exception conditions. 

it may have been inadvertently sent by another The select(2) call returns information indicating 
process. A 7SIGNL notification should be used as which of the conditions specified in the input actually 
an indication that some event may have occurred, 45 exist (Le. which of the specified descriptors are ready 
and some other .leans used to find out if it actually f or reading, writing, or have exceptions on them). The 
has. For example, a queue may need scanning, or a call can be made to pend until one of the specified con- 
flag checking. ditions exist, or it can be polled. 

* Don't assume that you will get a notification for GUES arranges for gui_runO to call select(2) in a 
every 7SIGNL sent. 50 pended fashion, whenever there are no jobs to run from 

Whenever a notification is received, all outstanding a pended gui_run(). Also, an impended gui_run() will 

work should be checked (e.g. a complete queue scan do a polled select(2) call whenever there are no jobs 

done) rather than assuming that you will get one notifi- already queued within GUL 

cation for each piece of work to be done. Each subscriber to the GUES select service has a set 
GUES will, however, guarantee to give you another 55 of File Descriptor masks, which mimic the select(2) 

notification for any ?SIGNLs received after a notifica- masks. The subscriber passes a pointer to his/her 

tion starts to run, so there are no situations where work GUES— SELECT— MASK structure into gues_sub- 

wmbelostduetoa?SIGNLarrivmgdmnnganotifica- scribe, and GUES remembers it The readfdsQ, wn- 

tion tefdsQ, and exceptfdsQ masks which GUES specifies to 
13 2 Unix signal(2) Events 60 select(2) are then constructed by OR'ing together the 

This subscription allows multiple GUES users to be masks of all the subscribers. Hence by manipulating bits 

notified upon receipt of Unix signal(2) events. in his/her GUES-SELECT-MASK, the subscriber 

Fa rfr subscriber passes the signal number of interest can dynamically add or remove a given file descriptor 

into GUES, and GUES establishes a signal handler from the set of files he/she is interested in being notified 
(using sigset(2)), for that signal. Various signals are of 65 about 

use to applications: the SIGUSR1 and SIGUSR2 sig- Whenever a select(2) call indicates an I/O condition, 

nals can be used in a similar way to 7SIGNL under GUES will schedule a single notification for each sub- 

AOS/VS (as a Fast IPC mechanism), whilst other sig- scriber whose select mask specifies one or more of the 
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descriptors with conditions on them. Only those sub- This routine allocate; an internal GUI qua*. onto 

scribers whose masks show that they are currently in- which jobs can be scheduled by gui_schedulep. In 

terested in the files with conditions on them will receive order to run jobs off this q^ue, the user must caU gui- 

tificatio — runO on the same thread (VS-Task), which allocated 
3 Tallowing warnings apply to users of this service: 5 it. If the 'user_wakeup > routine is specified, then this 

• ■ S« may teWto cL subscriber interested will be called whenever a job is scheduled, and on the 

STgivi-ffle descriptor, so some care must be thread which scheduled rt. T*e ^r sho^d then call 

token to handling the notification. For example, if S^-^on the thread which allocated the quid. 

twosubscn^rssettteirselectrx^^ ^edlaV, to be run on a specific thread, 

interest in a read being possible on STD1N, then JU ^ UCUU1C J ' K 

scriber reads all the available input from the^otj "—^ ^ ^ ^ ^ 8hould ^ scheduled, 

cation routme, and then &e second subscnl^ at- quid a quid returned from a previous 

tempts a read, the read wfll pend, perhaps for ever! ^ ^ ^^^^ 

When using a well known file descriptor (such jj ^ f ^ to which a call is 

STDIN), it may be advisable to do a further polled being scheduled 

select(2) call from the event notification, in order to ^1^4 Arguments, with which the scheduled 

check that the condition still exists, ^ ^ ^ rou tmes will be called, 

* It is equally important that one of the notifications Schedu ies a routine to be called on a particular quid, 
clears the I/O condition, or else that all the sub- ^ rou£me ^ get called (with time specified argu- 
scribers clear the offending bits in their select ments ) wnen the user calls gui_run from the thread 
masks. In the above example, if neither notification wn i cn allocated the quid. GUI transparently passes the 
reads the available input, and they both leave their 25 ^^3^ 0 f four INT32s (argl-arg4) to the scheduled 
select masks unaltered, then the process .will go . routme . By agreement between the scheduling and 
into a hard loop, because every time GUES calls scheduled routines, these parameters may be used to 
select(2), it will show I/O possible, and the sub- pass any number of parameters, each of any size, so long 
scriber notifications will be scheduled again. ^ ^ occupied by them is no greater than 

* If any of the subscriber select masks specify a file 3Q ^ use ^ b y four INT32s. Effectively, GUI copies four 
which is not currently open, then GUI will get an double-words of stack from the scheduler to the sched- 
error from select(2), and will terminate the process. ^3 routine, and the interpretation of this block is left 
Subscribers must therefore be careful to amend ^ ^ usen 

their select masks whenever they close a file. Also, gui_ run 

if a file is visible to multiple GUES subscribers, 35 Run previously scheduled routines. 

then anyone closing that file must define a mecha- Format 

nism for informing the other subscribers, so that guL_nm(flag) 

they can amend their select masks also. Parameters: 

Note that GUES only does select(2) calls from the flag indicates whether the caller wants to wait if no 

well defined points mentioned above. In particular, 49 j 0 t> s are ready to run. Set to PEND, or NOPEND. 

GUES can never make select(2) calls whilst a user noti- This routine causes previously scheduled jobs to be 

fication is running (since there is only a single base level ran. jobs are selected in priority order from the quids 

path), and so as long as the user's select mask is valid allocated by the calling task. 

whenever gui_runO is called (or returned to) no prob- if GUI_OPTION_NOPEND is selected, GUI will 
lem will arise. 45 return to the caller either after running one job, or if 

Clearly, this subscription must be used with care but non e are available, 

if so used it provides a powerful service. If GUL-OPTION_PEND is selected, GUI will not 

Chapter 8 GUI Interface Specification return, until the user calls gui-wakeup. It win sleep if 

This Chapter is a functional description of the pre- no jobs are ready, and run them as they become avail- 
ferred form the GUI interface as a specific example. 50 able, 

gm ini tialis e Initialises the GUI environment gui-wakeup 

Format gui_mitialiseO Cause a pended gui— run to return. 

This routine must be called by each library, and by Format: 

the main application, before any other GUI routine can gui-wakeup (quid) 

be called. 55 Parameters; . 

gui-allocate_quid quid Specifies that the thread which owns quid , is 

Allocate a queue for job scheduling, and return its the one to be awoken, 

identifier. The user calls this function in order to cause a thread 

Format: gui— allocate— quid (priority, user_wakeup, which has called gui_run with the pend option, to 
Quic r) 60 return when it finishes running the next job. The speci- 

Parameters: fied 'quid' must be owned by the thread which is to be 

priority Defines the relative priority of jobs sched- awoken. ^ 

uled onto this queue. If the thread is currently waiting for a job to run, then 

user_wakeup If specified (non-NUIX), this routine it will return immediately. If it is not currently within 
will be called by GUI, whenever a job is scheduled 65 gui_run() at all, then its next call to gui_runO will 

onto this quid. return immediately, 

quid GUI fills in this parameter with the Queue Iden- A routine may also be provided to check that aqmd 

tifier for the newly allocated queue. is valid, without having to schedule ajob onto it This is 
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useful for GCSPs, who can use it to check that the quid 
passed into a service request routine by a user is valid. 
This prevents the GCSP from discovering, later in its 
processing, that the quid is invalid, and not being able to 
tell the user. 5 

The user will _also provide user— job Scheduled Rou- 
tine fox the calling sequence for jobs which the user 
gui-schedule's, with the arguments specified when the 
job is scheduled with the call to gui— schedule, and with 
the quid on which the job is scheduled. The user can use 10 
quid to re-schedule jobs onto the same quid, or on a call 
to gui— wakeup if it wishes the thread on which it is 
running to return from gui runQ. 

Chapter 9 GUTS Interface Specification 

This Chapter provides a functional description of one 15 
example of a GUTS interface, 
guts— initialise Initialise the GUTS library. 

This routine should be called by each component, 
before any other GUTS routine is called. All but the 
first initialisation is ignored by GUTS. 20 
guts— start-timer GCSP Request Start a GUTS timer. 

Format: 

guts-start-timer (nfunc, quid, delay, uargl, uarg2) 
Parameters: 

nfunc This is a user notification routine, which will be 25 

scheduled by GUTS when the timer expires, 
quid This is the quid onto which 'nfiinc' will be 

scheduled when the timer expires, 
delay The number of seconds which must elapse 

before the timer expires, and 'nfunc' is scheduled 30 

by GUTS. 

uargl This parameter is passed transparently back to 

the user on the notification routine. 
uarg2 As uargl. 

This routine is called in order to start a once-off timer 35 
event. When the timer expires, in 'delay' seconds, 
GUTS will schedule the user notification such that it is 
called from gui_run(), thus: (*nfunc) (uargl, uarg2, 
quid). Other parameters may be employed to uniquely 
identify a single timer. 40 

A good way to ensure uniqueness between several 
entities using GUTS, is to use a pointer to a control 
block for a 'user— ref parameter. So long as the control 
block remains allocated, no other entity can allocate 
memory at the same address and hence the 'user— ref is 45 
unique. This approach also means that it is a simple 
matter to locate the operation which was being timed. 

If a regularly repeating timer is required, a timer of 
the same (or different) name can be scheduled from the 
notification routine, each time the timer expires. 50 
guts cancel— timer 

Cancel an outstanding timer. 

Format: 

guts .cancel rimer (identifiers, timeleft) 

Parameters: 55 

identifiers Identify the timer uniquely 

timeleft If the timer is found, and successfully can- 
celled, GUTS returns the amount of time which 
remained before the timer would have expired. 

This routine can be called to cancel an outstanding 60 
timer, which was previously started with guts— star- 
t—timer 0* This is useful if, for example, the event being 
timed completes normally, or is aborted, 
guts— check timer 

Check to see how long remains before a timer will 65 
expire. 

Format: 

guts check— timer (identifiers, timeleft) 



Parameters: 
identifiers As above 

timeleft GUTS returns the time remaining before 
expiration in this parameter. 

This routine can be called in order to check how long 
is left to go before a specified timer will expire. This is 
useful for reporting information to management appli- 
cations. 

Chapter 10 GUBS Interface Specification 

This Chapter provides a functional description of one 
example of a GUES interface, 
gues— initialiseO Initialise the GUES library. 

This routine should be called by each component, 
before any other GUES routine is called. All but the 
first initialisation is ignored by GUES. 
gues— subscribeO GCSP Request 

Ask to be told about a class of events. 

Format: 

gues-subscribe (gui— quid, in— pars, out— pars) 
Parameters: 

gui— quid Specifies a GUI quid, on which the caller 
wishes to be notified of event receipt. The notifica- 
tion routine specified in 'in— pars' will be scheduled 
onto this quid each time the event is received. 
in_ pars Input parameters for the registration. See 

example below, 
out— pars Output parameters for the registration. See 

example below. 
A user calls this routine in order to register an interest 
in external events, such as AOS/VS Fast IPCs 
(7SIGNL), UNIX Software Interrupts (signals), or 
child process terminations (obituaries). 

The 'in- pars' packet, contains the type of event, the 
address of a notification routine to be called on receipt 
of the specified event, plus any parameters specific to 
that event 

The 'out—pars' packet contains any information re- 
turned by GUES about the registered event 

Some examples of the form which these packets may 
take follow: Subscribe to VS 7SIGNL events Sues— 
subscribeO call: 

.Input parameters: 

typedef struct gues— in_ pars 

event-type Set to the value GUES EVENT VS 
SIGNL. 

nfunc This is the address of the user notification rou- 
tine, to be called by GUES on receipt of the event 

udata User data, to be passed into 'nfunc 1 . 

Output Parameters: 

typedef struct Sues— out—pars 

sub— id GUES returns an Identifier for this subscrip- 
tion. 

wait— task— uid This member specifies the VS Unique 
Task ID of the internal GUES task which is being 
used to await the event. This is needed in order to 
?SIGNL the task. 
This event is available only under AOS/VS. On re- 
ceipt of a Fast IPC, the caller's notification routine will 
be scheduled, such that it is called thus: 

(♦nfunc) (sub— id, event— type, udata, 0, gui— quid); 
The 'gui— quid' is the quid on which the notification is 
being run. 

Subscribe to Interrupt events gues — subscribeO call: 
Use of parameters for Software Interrupt event sub- 
scriptions. 
Input parameters: 
typedef struct gues in- pars 
event-type Set to the value GUES— EVENT_INT. 
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int_ num This is the "interrupt number", to which the 
caller wishes to subscribe. Under UNIX, this is a 
signal number (defined in signal, h). 

nfunc This is the address of the user notification rou- 
tine to be called by GUES on receipt of the event 5 

udata User data, to be passed into 'nfunc' 

Output Parameters: 

typedcf struct gnes signl .out— pars 

sub— id GUES returns an Identifier for this subscrip- 
tion. 10 

This subscription allows multiple entities within a 
process to be notified upon receipt of a signal, e.g. under 
UNIX. 

On receipt of the specified interrupt, the caller's noti- 
fication routine will be scheduled, such that it is called 15 
thus: 

(♦nfunc) (sub—id, event— type, udata, int nnm, gui- 
_quid); 

The 'gui— quid* is the quid on which the notification is 
being run. 20 
Subscribe to child obituaries gues_ subscribeO call: 
Use of parameters for subscriptions to child obits. 
Input parameters: 
typedef struct gues in pars 

event-type Set to the value GUESLEVENT-O- 25 
BIT 

nfunc This is the address of the user notification rou- 
tine to be called by GUES on receipt of the event. 

udata User data, to be passed into 'nfunc' 

Output Parameters: 

typedef struct gues_ signl— out_pars 

This subscription is supported under AOS/VS and 
UNIX. It allows one or more entities within a process to 
be notified upon termination of a child process. Upon 
termination of a child process (or of a partner in an 
AOS/VS Customer-Server relationship), the caller's 
notification routine will be scheduled, such that it is 
called thus: 

(♦nfunc) (sub .id, GUES— EVENT—OBIT, udata, 
obit_ptr, gui_jquid>, 

The *gui— quid' is the quid on which the notification is 
being run, and *obit— ptr' is a pointer to the following 
structure: 



USINT32pid; 
USINT32 status; 
} GUES-OBIT; 
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pid This field contains the PID of the terminated 
process. 

status This field indicates how the process termi- 
nated. 

Under AOS/VS, it contains zero for a normal tenni- 55 
nation, or else an error code. This error code may be 
returned from the terminated process (via ?RETURN), 
or be supplied by GUES to represent an abnormal ter- 
mination. 

Under UNIX, 'status' contains the exit status of the 60 
terminated child, as obtained from the wait3(2) system 
call, documented in UNIX. 

Subscribe to select(2) events gues_subscribe() call 

Use of parameters for subscriptions to select(2) 
events. 65 

Input parameters: 

typedef struct gues— select-mask 

typedef struct gues m pars 



event-type Set to the value GUES-EVEN- 
T_ SELECT 

select— mask This field must contain a pointer to a 
GUES— SELECT— MASK structure. If this struc- 
ture is dynamically allocated, then it must not be 
freed since GUES continues to access it for the 
duration of the process. — 

nfunc This is the address of the user notification rou- 
tine, to be called by GUES on receipt of the event. 

udata User data, to be passed into 'nfunc'. 

Output Parameters: 

typedef struct gues out pars 

sub_id GUES returns an Identifier for this subscrip- 
tion. 

This subscription allows multiple users to be notified 
of I/O conditions, as implemented by the select(2) sys- 
tem call. Each subscriber to this GUES service has a set 
of Hie Descriptor masks, which indicate which files the 
subscriber is interested in Head, Write and Exception 
conditions upon. 

Whenever a select(2) call indicates an I/O condition, 
GUES will schedule a single notification for each sub- 
scriber whose select mask specifies one or more of the 
descriptors with conditions on them. Notifications will 
be scheduled such that thy are called thus: 

(♦nfunc) (sub_id, GUES— EVENT—SELECT, 
udata, mask ptr,gui— quid); 

The *gui_ quid* is the quid on which the notification is 
being run, and 'mask— ptr* is a pointer to a GUES— SE- 
LECT— MASK containing the output from the se- 
lect(2) call (Le. it indicates which conditions are present 
on which files' descriptors). 

user— event— receivedO User Notification 

Calling sequence for event 

Format: 

void user— event—received (sub— id, event— type, 

udata, event-param, gui— quid) 
Parameters: 

sub_id This is the Subscription ID, which was re- 
turned by GUES when the user subscribed to the 
event which is being notified, 
event—type This indicates the type of event which 
has arrived (GUES-EVENT-VS-SIGNL, 
GUES—E VENT— INT, GUES— EVENT— OBIT, 
or GUES— EVENT— SELECT), 
udata This is a user data parameter, which is passed 
transparently by GUES. It has the value specified 
by the user on the subscription, 
event-param The use of this parameter is dependent 

on the particular event type, 
gui— quid Specifies the GUI quid on which the notifi- 
cation is being run. 
This routine gets called when an event which has 
previously been subscribed to is received. Note that the 
name of this routine is actually assigned by the user, and 
its address passed on the subscription call. The name 
'user— event— receivedO' is used simply for example. 

Unlike GUTS timers, event subscriptions remain in 
force for the duration of the process invocation. There 
is no need to renew a subscription from the notification 
routine. 

Chapter 11 GUI Programming Example 
This Chapter shows the use of GUI to implement a 
simple GCSP, which provides an impended read ser- 
vice. It also shows a simple User, which invokes the 
services of the GCSP, to perform impended reads. The 
example is written in the *C language, but is not in- 
tended as a complete program. Rather, it is intended to 
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illustrate GUI usage. This example is specific to 
AOS/VS, since it uses a slave AOS/VS task to do 
pended I/O. This is not the way GUI should he used if 
UNIX portability is an issue, however, a more realistic 
example would be unnecessarily complex and less in- 
formative. ._ 

The example is also rather lax on error checking. Any 
real user of GUI should be sure to check return codes 
exhaustively, since the effects of failed GUI requests are 
likely to be serious and difficult to trace later on. 



32 

-continued 



* User's main task; passing the full data buffer back as 

• 4 argT V 

guL_schedule (rcad_pkt-> notification— *jukl, 
read— pku> iiotification-routine, 
read_pkt->buff 



10 } 



/• Free up the internal request packet •/ 
free (rearf-.pkt); 
return (OK); 



End GCSP Code 



Globals 

GUI— QUID slave—quid; /• Quid allocated to GCSP slave task V 
GUI—QUID user— quid; /* Quid of user's main task •/ 
End Globals 

GCSP Code 
/•GCSP-initO* 

• Routine to be called by user, to initialise the GCSP. 

• Spawns a slave VS-Task, to do pended requests. 
V 

GCSP_w, o GCS^-slave 0; 
mtask (GCSP-slavc, SSTACK. SIZE); /* start slave task */ 

/* GCSP-slave 0 
• 

• Runs as a slave VS-task. Just calls gui—run. from where any 

• scheduled calls will be run. 
V 

GCSP— slave 

gui_allocate_jquid (1, NULL, &slave_quid); 
while (TRUE) 

/• Run any routines the GCSP tells us to. V 
gut-run (GUI—OPTION-PEND); 

/* GCSP— async— readO 
• 

• The unpended read Request routine. Builds an internal 

• representation of the request (understood within the 

• GCSP), and prh^"^ it to run on the slave task. 
• 

• The slave will call the users notification routine, when the 

• read is done.*/ 

GCSP_async_read (Nfunc, quid, buff; rp, nbytes) 

void (*Nfunc) 0; /* Users notification routine V 

GUI— QUID quid; /* User quid to run notification on V 

char *buff; /* Buffer, to read into V 

FILE *fp; /* File descriptor to read from •/ 

INT32 nbytes; /* Number of bytes to read V 

{ 

READ— PKT •rcad-pkt; 
extern slave— readO; 

/» Allocate an internal request packet, and fill in 

• parameters from our arguments. */ 

read_pkt = (READ— PKT *) alloc (sizeof . (READ— PKT)); 
read_pkt- > notification— quid = quid; 

read— pkt- > notificatioB routine = Nfunc; 

read— pkt->fp = fp; 
read— pkl-> buff = buff; 
read— pkt-> nbytes = nbytes; 

/* Schedule the pended read to happen on our slave task 
guL-schedule (slave-quid, slave— read, read-pkt); 
/• ... and return V 
return (OK); 
} 

/* slave— readO 
• 

• This GCSP routine actually does the pended read. 

• It is run from gui—run, on the slave task, when scheduled by 

• OCSP-async rrarfQ.*/ 
slave— read (read— pkt) 
READ— PKT •rcad-pkt; 
{ 

/* Do the pended read. V 

fread (read_pkt->buff, read_pkt-> nbytes, 1, read— pkt->fp); 
/* Request done - schedule the notification back onto the 



User Code 

\$ /» The User's main routine. This simple example just issues 

* Unpended reads and waits for them to complete, until the 

* Eod-Of-F2e is reached.*/ 
USER mainQ 

> 

FILE *fp; 
20 char buff [SBUFF— SIZE]; 
extern USER— read— done 0; 
/• Initialise the world. V 
gui— initialise 
GCSP— init 0; 

gui— allocate— quid (1, NULL, &user— quid); 
fp « fopen ("tcstfile". V); ' 
whfle(Ifeof(f>)) 
{ 

/♦ Make unpended request. •/ 

GCSP— async— read (USER— read— done, user qu irt , buff, fp); 
/• in practice, the user would do some other processing 

* here. Also, there would probably be multiple requests 

* outstanding. 

* For simplicity in this example, we just wait for the 

* read to complete. V 

(GUI— OPTION— PEND); 
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} 

> 

/• USER— irart complete 
• 

* The user's notification routine, called by GUI, from gu i run, 

* when the request completes. 

* It does some processing of the received data, and then calls 

* gui_ wakeupO* *o that when we return, the task will return 

* from gui—run, enabling another request to be made. */ 
USER -trad done (buff) 

char *buff0; /* This is 4 argl' •/ 

process— data (buff); /* Don't care what it does V 
45 gui— wakeup (user— quid); 
return (OK);{ 
End User Code 



Chapter 12 Internal Structure 

50 This Chapter represents the design of the AOS/VS 
version of GUI. The UNIX and MS-DOS versions can 
be as ^"inflr as possible, though there will be differ- 
ences. At points in this specification where there are 
specific, evident, differences or issues, these will be 

55 noted by comments in square brackets, thus: [UNIX: 
Text of UNIX issue]. 

GUI has a very simple structure, illustrated in FIG. 
18. GUI is represented by the heavy line block 180 
consists merely of a set of queues, of which four are 

60 shown here, denoted Q1,Q2,Q3,Q4, containing Notifi- 
cations waiting to be run. Queues are allocated by calls 
to 'gui— allocate-jquidO*. Notifications are placed on 
queues by calls to 'gui— schedule^, and taken off 
queues by 'gui_run(y, as illustrated. FIG. 18 does not 

65 show the other GUI routines. 

GUI forms the basis of the tasking and flow of con- 
trol environment for the network communication sys- 
tem. 
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The User application 181 makes impended requests of 
one or more GCSFs, two GCSPs 182 and 183 being 
illustrated. These GCSPs may, in torn, make requests 
of other GCSP's and GCSP 182 and GCSP 183 are 
shown communicating with each other over path 184 in 5 
the example of FIG: 18. 

In the course of its processing, a GCSP may schedule 
routines to be called, in itself, in another GCSF, or in 
the User. This scheduling is indicated by the arrows 185 
from the GCSFs to 'gui_schedule\ and results in a 10 
notification being put on to an internal GUI queue, to be 
picked up by < gui_run\ Typically, the scheduling will 
be done from a separate VS-task awaiting external 
events. [UNIX/MS-DOS: From interrupt level.] 

Scheduled routine calls get run when the User calls 15 
'gui_ run*. This is shown by the arrows 187 from the 
Queues Q1-Q4 into *gui run 1 and the arrow 188 from 
User 181 into gui runQ . . . The scheduled calls may 
result in routines in the User 181, or within GCSPs 182, 
183 being called, again as shown by arrows 186. 20 

As previously noted, the User may need to schedule 
routines on to quids. This is shown by the connection 
189. 

Chapter 13 Data Structure Specification 

Because of the transient, and runtime specific nature 25 
of GUI notifications, there is no need to preserve any 
information across process invocations. All of the GUI 
structures are therefore memory resident There are no 
on-disk structures. In the following data structure pic- 
tures the sizes of various members (pointers in particu- 30 
lar) are shown as they would be on the MV. These are 
not necessarily the same as on the PC. 
13.1 The GUI Queues 

The main data structures within GUI are the job 
queues. These form the only coupling between 'gui- 35 
-schedule', and *gui_ run*. The job queues are an- 
chored off per-task headers, which are themselves on a 
linked list, anchored in a single Queue-descriptor. 
Hence there is only one global anchor, off which all 
GUI structures hang, directly or indirectly. 40 

The entries on the job queues are Notification Con- 
trol Blocks (NCB's), containing the information neces- 
sary for GUI to run the requested notifications, with the 
indicated parameters. 

A typical arrangement is shown in FIG. 19. This 45 
example shows Job Queue lists for S N' owners (VS- 
tasks). [UNIX/MS-DOS: There is only one owner.] 

Owner 1 has two 'quids' Job Ql and Job Q2 allo- 
cated, with two jobs scheduled onto the first of them, 
and none on the second. Owners 2 and N, each have one 50 
quid allocated, with no jobs scheduled. 

All the lists are doubly-linked MV queues, so that the 
MV hardware queuing instructions can be used. These 
instructions are atomic, and eliminate the need for 
locks. [UNIX/MS-DOS: If the hardware in these envi- 55 
ronments does not provide similar instructions, then it 
may be necessary to disable interrupts for the duration 
of Enqueues and Dequeues.] 

13.1.1 GULJROOT Descriptor 

This is the root anchor for all GUI queues. It has the 60 
structure shown in FIG. 20. The two members are 
pointers, which point to the First and Last Owner 
Queues. As with all MV queues, these members are 
both —1, if the Q is empty. 

13.1.2 Per-owner list anchor 65 
This structure is what is on the list anchored in GUI- 

_ROOT and is illustrated in FIG. 21. It contains *nextf 
and 'pre/ pointers, an owner id, and a Q descriptor for 



the list of 'quids* owned by that user. The Job Queues 
hanging off this anchor are sorted in priority order. 
There are also some fields used to control access to the 
Q by the owner. 

The 'owner* field identifies the Owner task of the Job 
Queues on this list In order to avoid the overhead of 
system calls to discover the VS-Task-ID, the Stack Base 
of the Owner task is used for this identification. This 
approach is in common with the DG Language Run- 
time libraries, and therefore imposes no extra con- 
straints. 

The < mbox\ is an inter-task mailbox, on which the 
owner waits if he does a pended *guL-run', when there 
are no notifications scheduled on any of the owned job 
queues. The task will be awoken when another task 
does a 'guL-scbedule', or t gui— wakeup', on a 'quid* 
owned by this task. VS inter-task system calls (?REC 
and 7XMT), will be used for this purpose. [UNIX/MS- 
DOS: The wakeup will be done from interrupt leveL 
Spin locks will be used for MS-DOg, and a "selectO" 
system call for UNIX.] 

The 'status* field contains various control bits, and is 
defined in FIG. 22. The •running' bit is set when GUI is 
running a notification -for this Owner and is used to 
prevent nested calls to •gjii_run\ The 'waiting* bit is 
used when the task is waiting on the 'mbox\ The •wa- 
ke— up' bit is set in order to cause a running task to wake 
up after the currently running job. The 'job—scheduled' 
bit is set by gui— schedule, whenever a job is scheduled. 
This closes the. window which would otherwise exist, 
when a job gets scheduled whilst another VS-Task is 
searching for a job to run. 

13.1.3 Job Queue Anchors 

This structure is what the actual NCB's for a given 
•quid', are anchored to. It is shown in FIG. 23 and con- 
tains the Job Q id 'quid', and its priority, plus the usual 
Q descriptor, for the NCB's. 

13.1.4 Notification Control Blocks 

These are the control blocks, which are queued onto 
the Job Q's. Each one represents a Notification which 
has been scheduled, and contains all the information 
required to run it 

These control blocks have the format shown in FIG. 
24. The 'next' and 'prev' fields point to the next and 
previous NCB's on this Job Q. The other members are 
the parameters passed to 'gni runQ' and which will be 
passed to the notification routine, when it gets run. 

It can be seen from this structure, that the memory 
requirement for each outstanding, scheduled notifica- 
tion, is 7 double words (28 bytes). It will be left to the 
GUI Users to ensure that memory is available for these 
blocks. If GUI cannot allocate an NCB when it needs 
one, it will return an error from 'gui_schedule0^ 
13.2 Quid Table In order to speed-up access to the GUI 
Job Queues, there is a table, indexed by 'quid', which 
gives the location of the Job Q identified by *quid' Each 
entry in this table has the format shown in FIG. 25. 

To avoid the need to lock the quid table, entries are 
written atomically. An unallocated quid will have the 
value NULL in the *job_q_ ptr 1 field of its table entry. 
During allocation, this field will be filled in atomically, 
as the last stage of the allocation, at which point the 
quid becomes valid. 

Again, to avoid the need for locks, the table can be a 
fixed size, of 256 entries. This imposes a limit on the 
number of available quids, of 256. A shared access 
scheme can alternatively be implemented, allowing 
shared read-only access of the quid table, but exclusive 
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write access, so that the table can be grown when it 
becomes full. 

Quids are allocated started at a value of 1, leaving the 
value 0 free as a special value (NULL— QUID). Addi- 
tionally, all negative values are invalid, and reserved for 5 
special meanings. 

13.3 Within the context of the data structure described 
above by way of example, this Chapter concludes with 
a single example of the actions which may be taken by 
one of the GUI modules, namely procedure guL-al- 10 
locate-jquid (priority, user— wakeup) begin 
get the callers stack base; 

search the owner Q chain for an anchor owned by 
this task; 

if (owner anchor not found) 15 
begin 

allocate a new per-owner list anchor, 
fill it in; 

add it to tail of the owner Q chain; 
end 20 
allocate and init Job q anchor; 
put allocated quid into Job Q anchor; 
put user— wakeup into Job Q anchor, 
add Job Q to the owners Job Q chain, at a point 

determined by priority; , 25 

obtain the next available quid, and claim that slot in 

the quid table; 
put pointers to the owner anchor, and Job Q, mto the 

claimed slot; 

return the quid just allocated; 30 
end. 

The module specifications for gui_schedule, gui- 
_xun, etc. can be analogously derived. 
13.4 GUI Memory Management 

GUI can have its own memory management scheme, 35 
consisting of a pool of memory blocks, of suitable sizes 
for the NCB's, Job Q*s, and Owner Anchors. The aim of 
this scheme is to provide a more efficient allocation 
mechanism than the standard C runtimes, based on the 
knowledge that most of the memory required will be in 40 
blocks of the same size. However, the standard C func- 
tions 'alloc* and free' may be used. 

Chapter 14; GUI and Communications Server . Sys- 
tem 

FIGS. 26A, 26B illustrate the basic outline of the 45 
operations which result when a message is received 
from a network interface and needs to be sent to its 
destination. This is given purely as a simplified example 
in order to avoid obscurity arising from excessive detail. 
The notification that there is a message to send will 50 
come from the specific routines 45 (FIG. 3) in the form 
of an IPC from another server process. It is assumed 
that the software interface 44 is waiting within gui- 
_run(pend), as indicated at 262. At 264, the IPC comes 
in and puts a routine on a GUI quid. If the gateway is a 55 
CEO gateway 12A, for example, this will be a routine 
ceo-msg-rcvdO 266. Because the software interface is 
in gui— run(pend), ceo msg-rcvdQ will be run and will 
schedule another routine, namely build-PDUO 268 
which will likewise be run. This routine is a TOOLS 60 
routine which implements functions well understood 
per se; it builds a PDU in X400 1988 format as used on 
the UMB, making use of ARTX400, by getting each 
field from the CEO message, converting it to the UMB 
format and adding it to the FDU being built This can 65 
be done by a simple add item routine additemO which 
can be implemented conventionally, without going 
through the procedure of being gui-scheduled and 



gni run, since ART routines do not do a lot of process- 
ing. 

Ceo-msg-rcvdO also schedules a GCSP request 
TOOLS-sendO 270 which sends the message out on to 
the universal messaging backbone 15. TOOLS-sendO 
firstly performs internal processing.272 in which it goes 
through the recipient list for every recipient (there may 
be more than one in general) and makes a directory 
look-up for every recipient, as indicated at 274. The 
directory look-ups are handled by a separate directory 
server process, also running, within gui— runO 276, each 
look-up being initiated by an IPC 278 and the results 
being returned by IPCs 280. Directory completion is 
determined at 282 for each look-up in turn and then the 
message is submitted to GCSP request routine 284 
(FIG. 26B) mti__send(X which implements the actual 
sending over the UMB 15. The network connection is 
established at and the event "connected" 288 is sig- 
nalled via the routine mtLxonnected 290. TOOL- 
S— data— accessO 292 then gets the message data from 
disk and data send 294 takes place. This procedure is 
followed for all recipient gateways in turn. 

For simplicity only the barest outline of the protocols 
followed in message transmission are here given. The 
Figures do not illustrate the data confirmation proce- 
dures, nor the saves to disk which take place at various 
stages, e.g. where indicated by asterisks. Moreover the 
Figures cannot bring out the real essence of GUI, since 
they appear to illustrate a conventional sequence of 
routines which could be implemented in the normal 
manner of linear programming languages. The routines 
must indeed implement a sequence of operations, which 
must follow the well established principles of data com- 
munication, but the significant point about the imple- 
mentation in GUI is that the routines do not simply call 
each other in the correct sequence and pend until com- 
pletion. Rather their notification routines or jobs are put 
on to the GUI quids by calls to gui_schedule0 and run 
by calls to gui— run(X as explained above with reference 
to FIGS. 13 to 17. 

What is more, in a real life situation, many messages 
will be handled simultaneously, being in different stages 
of handling from message to message. This is more or 
less impossible to illustrate meaningfully in a drawing 
but it can readily be understood that GUI, as described 
above is ideally suited to handle this situation, since all 
the different notification routines or jobs to be run are 
put on to the GUI quids and they all get run in turn as 
a result of the calls to gui— runO- Also, in a communica- 
tions server system, jobs have varying priorities and it is 
easy to implement the different priorities by the use of 
quids with different priorities. 



IV ABBREVIA TIONS AND ACRONYMS 

AOS/VS 
ART 



ASN.I 



AU 
C 

ccnr 

CEO 

cs 

csn> 

DG 

DISOSS 
ECS 



Data General operating system for its MV computers 
ASN.I Run Times - library routines, decode/encode 
between transfer and internal syntax 
Abstract syntax notation 1, international (ISO) 
standard for abstract definition of the representation 
of data types 
Access unit 

Programming language 

International Telephone & Telegraph Consultative 
Committee 

Data General office automation system 
Communications server 
Called subscriber identifier 
Data General Corporation 
IBM Office automation system 
External calling sequence 
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IV ABBREVIATIONS AND ACRONYMS 

GCSP GUI-conformant service provider 

GUES Generic nnpm fieri event-handler service 

GUI Generic impended interface 

GUTS Generic impended tuner service 

ID Identifier 

IPC Inter-process communication - message passed 

between two processes 

I/O Input/output 

IBM International Business Macnhws Corporation 

ISO International standard! organisation 

LAN Local area network 

MRC Message-based reliable cnamiri, standard 400 Mb/s 
bus 

MTI Message transfer interface 

MS-DOS Standard operating system for PCs 

MV Data General computers running AOS/VS 

NCB Notification control block 

OS Operating system for a computer 

PAD Packet assembler/disassembler 

PC Personal computer (IBM or clone) 

PDN Public data network 

PDU Protocol data unit - information passed in single 

structured chunk 

PID Process identifier 

PROFS IBM Office automation system 

PSTN Public switched telephone network 

FTT Postal* telegraph & telephone ^ministration 

Q Abbreviation for Queue 

QUID Queue identifier 

RUA Remote used agent 

SNA Systems network architecture IBM network 

SNADS IBM message protocol 

VS - AOS/VS 

X25 Packet switching protocol 

X400 GCITT standard for message handling 

X500 CCITT standard for directory service 
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Note that reference should be made to published 35 
manuals for an explanation of AOS/VS terniinology. 
. The invention may be embodied in yet other specific 
forms without departing from the spirit or essential 
characteristics thereof. Thus the present embodiments 
are to be considered in all: respects as illustrative and not 
restrictive, the scope of the invention being indicated by 
the appended claims rather than by the foregoing de- 
scription, and all changes which come within the mean- 
ing and range of equivalency of the claims are therefore 
intended to be embraced therein. 45 

What is claimed is: 

L A digital computer system comprising (i) an oper- 
ating system, (ii) a plurality of routines operable under 
said operation system, and (iii) a plurality of queues for 
job data identifying routines to be run, said routines 50 
including routines in first, second and third modules, 
said first module including user routines, said second 
module including service routines providing services 
and said third module including interface routines, 
said user routines including routines requesting ser- 55 

vices from said service routines, 
said interface routines including a schedule routine 
callable by each service routine to place job data 
on a selected one of said queues and a run routine 
callable by a user routine to cause a notification 60 
routine identified by job diata on a selected one of 
said queues to be run, at least some said service 
routines providing return results for said first mod- 
ule of routines, 
wherein, said queues are in sets allocated to a plural- 65 
ity of different owners and wherein each owner 
can only call said run routine in respect of a queue 
which that owner owns; and 



wherein, following a request to a service routine, 
processing within said first module can continue 
without pending for a return result from a service 
routine. 

2. A digital computer system comprising (i) an oper- 
ating system, (ii) a plurality of routines operable under 
said operation system, and Cut) a plurality of queues for 
job data identifying routines to be run, said routines 
including routines in first, second and third modules, 
said first module including user routines, said second 
module including service routines providing services 
and said third module including interface routines, 

said user routines including routines requesting ser- 
vices from said service routines, 

said interface routines including a schedule routine 
callable by each service routine to place job data 
on a selected one of said queues and a run routine 
callable by a user routine to cause a notification 
routine identified by job data on a selected one of 
said queues to be run, at least some said service 
routines providing return results for said first mod- 
ule of routines, 

wherein each of said queues has a data structure in- 
cluding; 

(a) the priority level of the queue, 

(b) the identifier for the queue, 

(c) pointers to control blocks for the first and last 
notification routines on the queue, and 

(d) pointers to the next and previous queues, 

and wherein each control block has a data structure 
including: 

(e) pointers to the next and preceding control 
blocks, 

(f) a pointer to said notification routine, and 

(g) arguments to be passes to said notification rou- 
tine; and 

wherein, following a request to a service routine, 
processing within said first module can continue 
without pending for a return result from a service 
routine. 

3. A digital computer system according to claim 2, 
wherein said queues are in sets allocated to a plurality of 
different owners and wherein each owner can only call 
said run routine in respect of a queue which that owner 
owns, and wherein said data structure further includes a 
plurality of anchor structures, one per owner, and each 
including: 

(h) pointers to the next and preceding owner anchor 
structures, 

(i) a pointer to a stack base, 
(j) a plurality of status bits, 

(k) a pointer to an identifier for at least one queue 
owned by that owner. 

4. A network communication system including a 
plurality of gateways for serving respective access 
units, said gateways being connected to communicate 
with each other through a message handling system, 
wherein at least one gateway comprises: 

a network interface providing access to the access 

unit served by that gateway, 
a message transfer interface for sending messages to 

and receiving messages from said message handling 

system, and 

a software interface including a library of routines 
which provide communication between said mes- 
sage transfer interface and said network interface 
and process data passing through that gateway to 
effect at least format conversion, 
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and wherein said routines in said software interface 
include routines is first, second and third modules, 
said first module including user routines, said sec- 
ond module including service routines providing 
services and said third module including interface 5 
routines, _ 

said user routines including routines requesting ser- 
vices from said service routines, 

said interface routines including a schedule routine 
callable by each service routine to place job data 10 
on a job data queue and a run routine callable by a 
user routine to cause a notification routine identi- 
fied by job data on said queue to be run, at least 
some said service routines providing return results 
for said first module of routines, IS 

wherein, following a request to a service routine, 
processing within said first module can continue 
without pending for a return result from a service 
routine. 

5. A network communication system according to 20 
claim 4, wherein said run routine is callable with a flag 
indicating whether said run routine is to pend or not 
pend in the event there is no job data on said queue. 

6. A network communication system according to 
fflnim 5, wherein said third module farther includes a 25 
wake-up routine callable by a user routine to signal to 
said run routine when pended that it should return. 

7. A network communication system according to 
claim 4, wherein at least some of said service routines 
each takes an argument pointing to one of said notiflca- 30 
tion routines, enabling each user routine to pass a 
pointer to a selected one of said notification routines to 
be scheduled on to said queue. 

8. A network communication system according to 
rlaim 4, wherein there is a plurality of job data queues 35 
and said schedule routine takes an argument identifying 
which queue job data identifying a notification routine 

is to be placed on. 

9. A network communication system according to 
claim 8, wherein said queues have differing priorities 40 
and wherein said run routine runs notification routines 

in order of priority of their queues. 

10. A network communication system according to 
claim 9, wherein said run routine runs notification rou- 
tines within a queue in the order in which they were 45 
placed on said queue by said schedule routine. 

11. A network communication system according to 
claim 8, wherein said schedule routine takes as argu- 
ments said indication of which queue a notification 
routine is to be placed on, a pointer to said notification 50 
routine which is to be placed on said queue and a plural- 
ity of arguments for passing to said service routine. 

12. A network communication system including a 
plurality of gateways for serving respective access 
units, said gateways being connected to communicate 55 
with each through a message handling system, wherein 

at least one said gateway of said plurality of gateways 
comprises: 

a network interface providing access to a selected 
access units served by that gateway, 60 

a message transfer interface for sending messages to 
and receiving messages from said message handling 
system, 

a software interface which matches said message 
transfer interface, 65 

computer means for executing processing routines for 
handling at least one of messages to be transmitted 
and received messages, 



means storing a plurality of said routines which pro- 
vide communication between said message transfer 
interface and said software interface, and means 
storing a plurality of specific ones of said routines 
individual to that gateway and providing commu- 
nication between said network interface and said 
software interface, - 

wherein said specific routines convert between the 
format and protocols of the network interface and 
the format and protocols of said software interface 
and wherein communications between said gate- 
ways on said message handling system are effected 
in protocol data units including an envelope part 
and a message part, said envelope part including 
data identifying the message originator and non- 
gateway specific data identifying the message re- 
cipient, 

wherein said routines include service routines imple- 
menting services required during message han- 
dling, 

and wherein said computer means is operative to 
execute a main processing task including a plurality 
of said routines, during execution of a calling rou- 
tine of said main processing task to call at least one 
of said service routines, continue with further pro- 
cessing in said tnain processing task without pend- 
ing said at least one called calling routine, termi- 
nate said service routine and store job data identify- 
ing a notification routine, execute a run routine 
within said main task to cause a notification routine 
identified by stored job data to be executed. 

13. The network communication system of claims 12 
wherein said envelope part contains no data which is 
specific to the gateway serving the message recipient 

14. A network communication system including a 
plurality of gateways for serving respective access 
units, said gateways being connected to communicate 
with each through a message handling system, wherein 
each gateway of said plurality of gateways comprises: 

a network interface providing access to said access 

units served by that gateway, 
a message transfer interface for sending messages to 

and receiving messages from said message handling 

system, 

a software interface which matches said message 
transfer interface, 

computer means for executing processing routines for 
handling at least one of messages to be transmitted 
and received messages, 

means storing a plurality of generic ones of said rou- 
tines which provide communication between said 
message transfer interface and said software inter- 
face, and means storing a plurality of specific ones 
of that routines individual to said gateway and 
providing communication between said network 
interface and said software interface, 

wherein said specific routines convert between the 
format and protocols of the network interface and 
the format and protocols of said software interface 
and wherein communications between said gate- 
ways on said message handling system are effected 
in protocol data units including an envelope part 
and a message part, said envelope part including 
data identifying the message originator and non- 
gateway data identifying the message recipient 

15. A network communication system according to 
claim 14, wherein said message handling system is in 
accordance with the CCITT X400 Standard. 
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16. A network communication system according to ble by said other gateways via said message handling 
claim 14, wherein said message handling system is in system and said one gateway, 
accordance with the CCITT X400 Standard, 1988 ver- 23. The network communication system of clain 1 14 

wherein said envelope part contains no data wmcn is 
A network communication system according to 5 specific to the gateway serving the message recipient 
claim 16, wherein one of said gateways includes a net- 24. to a network commumcation system compr^a 
woA interface toCCITT X400 Standard, 1984 version. plurality of gateways for restive acc«, 

^ . units, said gateways being connected to communicate 

user agents. with each fhroiiKh a message handling system, a method 

18. A network communication system according to ~~ u-u e > » 

claim 14, m^ ^t^^ 

each said gateway and wherein said envelope part of g^J^ a Lss units served by that gateway, 
any protocoldata unit whose message part coasts of at m ^ ^ Message transfer 

least part of a document includes mfonnation identify. ^u^mmi* to ^ receiving mes- 

ing the document format, and wherein ^ ° f 15 sages from said message handling system, (c) processing 

specific routines of each gateway includes routes re- & m e eataing said network interface by a library 
sponsive to received information identifying said docu- of specific routines matched to said access units to pro- 
ment format of a received message to submit said mes- ^ ^ mtennediate mes sage in a system-standard for- 
sage part automatically to said document converter ^ ^ processing said intermediate message by a li- 
when said received mformation identifying said docu- ^ bfary of routines which are substantially the same 
ment format identifies a format incompatible with said m ^ gateways to form at least one protocol data unit 
access units served by the receiving gateway, whereby including an envelope part and a message part, said 
gateways are free to transmit in any document format envelope part inching data identifying the message 
without regard to said document formats acceptable to or jginator and data identifying the message recipient 
recipients. 25 but no data specific to the gateway serving said message 

19. A network communication system according to recipient, wherein said library of specific routines con- 
claim 14, including at least one directory accessible by verts ^tween the format and protocols of said network 
each gateway and wherein said routines include (1) interface and the format and protocols of said interme- 
routines which submit originating gateway data, said diate message and said library of core routines converts 
originating gateway data identifying the message origi- 30 between said format and protocols of said intermediate 
nator and the message recipient, to said at least one message and the format and protocols of said message 
directory for inclusion in a protocol data unit and (2) transfer interface, (e) transmitting said at least one pro- 
routines which submit message originator data and mes- tocol data unit on said message handling system via said 
sage recipient data from a received protocol data unit to message transfer interface. 

said at least one directory to determine at least said 35 25. A method according to claim 24, further includ- 
message recipient in the format required by said net- ing the steps of: 

work interface of that receiving gateway. (f) processing a protocol data unit entering said mes- 

20. A network communication system according to sage transfer interface by said library of core rou- 
claim 19, including a main directory unit holding a tines to form an intermediate message, 
directory which is directly accessible by all said gate- 40 (g) processing said intermediate message by said li- 
ways on said message handling system. brary of specific routines to form a local message, 

2L A network communication system according to (h) transmitting said local message to an access unit 
claim 20, wherein said main directory is a directory in via said network interface, 

compliance with the CCITT X500 Standard. 26. A method according to claim 24, wherein said 

22. A network communication system according to 45 message handling system is in accordance with the 
claim 19, wherein at least one gateway includes a direc- CCITT X400 Standard^l988 verskm. 
tory unit holding a directory which is indirectly accessi- 
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